sem all call nodes in generic type bodies + many required fixes

[metagn]

fixes #23406, closes #23854, closes #23855 (test code of both compiles but separate issue exists), refs #23432, follows #23411

In generic bodies, previously all regular nkCall nodes like foo(a, b) were directly treated as generic statements and delayed immediately, but other call kinds like a.foo(b), foo a, b etc underwent typechecking before making sure they have to be delayed, as implemented in #22029. Since the behavior for nkCall was slightly buggy (as in #23406), the behavior for all call kinds is now to call semTypeExpr.

However the vast majority of calls in generic bodies out there are nkCall, and while there isn't a difference in the expected behavior, this exposes many issues with the implementation started in #22029 given how much more code uses it now. The portion of these issues that CI has caught are fixed in this PR but it's possible there are more.

1. Deref expressions, dot expressions and calls to dot expressions now handle and propagate tyFromExpr. This is most of the changes in semexprs.
2. For deref expressions to work in typeof, a new type flag tfNonConstExpr is added for tyFromExpr that calls semExprWithType with efInTypeof on the expression instead of semConstExpr. This type flag is set for every tyFromExpr type of a node that prepareNode encounters, so that the node itself isn't evaluated at compile time when just trying to get the type of the node.
3. Unresolved static types matching static parameters is now treated the same as unresolved generic types matching typedesc parameters in generic type bodies, it causes a failed match which delays the call instantiation.
4. typedesc parameters now reject all types containing unresolved generic types like seq[T], not just generic param types by themselves. (using containsGenericType)
5. semgnrc now doesn't leave generic param symbols it encounters in generic type contexts as just identifiers, and instead turns them into symbol nodes. Normally in generic procs, this isn't a problem since the generic param symbols will be provided again at instantiation time (and in fact creating symbol nodes causes issues since seminst doesn't actually instantiate proc body node types).
   But generic types can try to be instantiated early in sigmatch which will give an undeclared identifier error when the param is not provided. Nodes in generic types (specifically in tyFromExpr which should be the only use for semGenericStmt) undergo full generic type instantiation with prepareNode, so there is no issue of these symbols remaining as uninstantiated generic types.
6. prepareNode now has more logic for which nodes to avoid instantiating.
   Subscripts and subscripts turned into calls to [] by semgnrc need to avoid instantiating the first operand, since it may be a generic body type like Generic in an expression like Generic[int].
   Dot expressions cannot instantiate their RHS as it may be a generic proc symbol or even an undeclared identifier for generic param fields, but have to instantiate their LHS, so calls and subscripts need to still instantiate their first node if it's a dot expression.
   This logic still isn't perfect and needs the same level of detail as in semexprs for which nodes can be left as "untyped" for overloading/dot exprs/subscripts to handle, but should handle the majority of cases.

Also the efDetermineType requirement for which calls become tyFromExpr is removed and as a result efDetermineType is entirely unused again.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from ab18962

Hint: mm: orc; opt: speed; options: -d:release
173583 lines; 8.013s; 654.484MiB peakmem

[arnetheduck]

is this appropriate to backport to 2.0?

[metagn]

In principle yes, it's not too crazy since it's mostly following up #22029, but if you ask me it's likely to cause some regressions, at least without #24005 which fixes some issues here (dot expressions need a universally working c.inGenericContext > 0), but could cause even more regressions due to the gravity of the changes.

Specifically 2 of the changes I think could cause issues, 1. the new dotexpr/subscript instantiation behavior, 2. the semgnrc change (which also needs a different diff for the opensym block). If the first one causes issues we'll need to fix it in devel too anyway, the 2nd one just needs the rest of the compiler to be ready for it which I think is true in devel and I can't think of anything the 2.0 branch doesn't have that would change it but I'm not sure. There are also minor things that maybe could cause issues but I don't really think so, like tfNonConstExpr and sigmatch using containsGenericType for the typedesc check.

It should also depend on another followup to #22029, #23863, which isn't backported yet. There might be more unrelated bugfixes that make it work.

In general I'm hesitant about the idea of backporting PRs like this where the goal is to make the compiler more "sensible" at the cost of stability, but maybe it's paid off for people before. In this case I think the benefit is little unless we also want to backport #24005 which I don't know about yet.