Instead of going through the `semTemplBody` indirection, directly check
whether the name part can be substituted with a template parameter.
This also prevents non-gensyms from being bound in the name position.

Using a dedicated branch requires less conditionals, and prepares for
changing the dot expression handling. Except for the edge case where a
quoted symbol choice (which is nonsense anyway) is inserted into a
template body by a macro, the behaviour stays the same.

Move the not-a-qualified-symbol handling into the `if s.isNil` branch.

This lifts the restriction that a gensym'ed symbol cannot be used in a
field access position. However, at the moment, it also causes symbols
such as `skVar` symbols to be bound there, which is incorrect.

Since gensyms don't reach into `semTemplSymbol` anymore, all
conditionals including them become false and are thus obsolete.

Only routine symbols and type / generic parameter symbols are
considered in field access positions, addressing the problem that
symbols of, e.g., locals blocked other symbols.

Symbol binding in generics for dot expressions works similar, with
the differences that:
* types and generic parameters are not considered there
* a *closed* symbol choice is forced, instead of an *open* one

Using an open symbol choice is wrong (it violates the specification),
but is required for backwards compatibility.

It's never incremented and is always zero.

* rename `isField` to the more imperative `noGenSyms`
* fix gensyms being added to the symbol choice, even if disabled (the
  flags of `s` were tested, not those of `a`)

It's now possible that the field part of a dot expression is a
identifier coming from a gensym. For example:

```nim
template t(x: int) =
  type Typ {.gensym.} = float
  x.Typ
```

So that field access still works in this case, `builtinFieldAccess` and
`propertyWriteAccess` strip the identifier off of the gensym prefix
first.

The `x.T` syntax now works when `T` is a gensym'ed symbos.

The `knownIssue` test is for a bug that's pre-existing.

The field part of a dot expression may now be a symbol choice, which
interferes with rendering of custom numeric literals (e.g., `1'lit`),
where the special rendering was only enabled for `nkIdent` and `nkSym`
nodes.

To keep the test working, `getPIdent` (which is used by `isCustomLit`)
now also returns the identifier for symbol-choice nodes.

This reverts commit 137c8a7.

Just retrieving the identifier from the symbol choice doesn't work,
since then the symbol-choice node is passed to `gident`, where `atom`
then crashes because symbol-choices are not allowed (a symbol-choice
is, not necessarily, an atom, so this is correct).

Instead of `getPIdent` retrieving an identifier from a symbol-choice,
`isCustomLit` now special-cases symbol-choices.

This restores the previous behaviour of quoted identifiers with regards
to symbol binding of (they ignore injected symbols, for whatever
reason).