consider instantiation errors in overload resolution as type mismatch

[metagn]

refs #24086

Instantiation errors encountered during overload resolution (such as when instantiating array range expressions based on existing generic parameters) are now saved for the current overload until overload resolution is finished and no overloads match, instead of immediately erroring globally. Encountering such errors also now treats the overload as non-matching. This allows other overloads that would instantiate normally to match even when no generic parameters are given.

Unfortunately I couldn't think of any tests that would encounter the errors created in semtypinst as the handling of tyFromExpr already doesn't create any errors. This doesn't give a great error message either, but going out of our way to error in semtypinst might make things worse.

Note: Covers #10220 but not #22964, which errors when calling generateTypeInstance in getInstantiatedType, which could also be handled. If we ever fix param constraints with instantiations, we should also handle this, which currently crashes the compiler:

proc foo[I](): array[I, int] = discard

let x = foo[int]()

In general this paves the way for generic instantiations to fail on constraint mismatches.