fix array/set/tuple literals with generic expression elements

[metagn]

fixes #24484

When an array, set or tuple constructor has an element that resolves to tyFromExpr, the type of the entire literal is now set to tyFromExpr and subsequent element expressions are left untyped rather than attempting to match them to the tyFromExpr type. The reason the subsequent elements are untyped is to not call fitNode on them which wouldn't work with a tyFromExpr type, but I haven't tested if it works if they keep their original types and fitNode is called on them during instantiation.

[Araq]

This makes me wonder where else we might have forgotten to handle tyFromExpr... And also, what the heck is tyFromExpr? I bet we don't really need it if types where just ASTs...

[metagn]

If "instantiating a type/node" was merged into just "semchecking a node" then we could probably do away with the inner node field, making it a nullary tyUnresolved or something like that. We would still need to use it during generic semchecking to propagate it. There is also the nuance of it becoming tyStatic or just being used for types of expressions (which enables tfNonConstExpr).

With this most of the "expression primitive" parts of the compiler propagate it but statements for example like assignments, if etc still do not (except when). In practice these would be moved into helper procs/templates though which would work.