sem: simplify generic parameter symbol handling

[zerbina]

Summary

Simplify type instantiation and logic related to generic parameters in general, by treating complex type expressions in generic contexts as generic expressions, with the symbols of generic parameters and parameters being bound during first-phase lookup already.

On the user-facing side of things, this fixes multiple long-standing issues with undeclared identifier errors for implicitly instantiated types. For example, the following previously failed:

type
  Type[B] = object
    a: typeof(B) # using 'A' here would make it compile!

proc p[A](): TypeOf[A] = discard

discard p[int]()

The is operator now also works properly in when expression of generic objects. An is expression that was not the top-level one (this includes not x is y and x isnot y) only checked for type equality and always evaluated to true when the right-hand side was a concept type.

Another important thing to note is that type expressions used in the header of generic routines are, except for those used in range type constructors, now generic expressions, meaning that non-immediate templates/macros and static statements are only evaluated once the type is instantiated.

On the compiler side of things, interactions with generic parameter symbols simplify, with a lot of conditional logic becoming obsolete. Instantiating types no longer requires opening a scope and adding all the bound types and static values as skType and skConst symbols.

One effect of the change is that generic parameter symbols are now always bound in type expression contexts, but never bound in generic procedure bodies.

Together, this should streamline generic parameter handling, making it more amendable to further changes / improvements in the future.

[zerbina]

This PR is currently on indefinite hold.

Because of issues related to wildcard generic parameters, the code as is doesn't work, and while I had made some local progress towards fixing them, the impact of the changes on semantic analysis would likely be too large (and the test suite regarding generics not exhaustive enough) at the moment.

Some of the fixes here, like not lifting typedesc return types for macros/templates, and the fix for generic macro/template return types, are standalone and can be split out into separate PRs.