simplify instantiation of generic types (`semtypinst`)

[zerbina]

Goal

Have semtypinst only produce fully resolved non-meta types (i.e., types that don't contain any unresolved generic parameters, type-classes, any, etc.).

Why?

At present, the type parameter application implemented in semtypinst supports two modes: with meta-types and without (signaled by the allowMetaTypes option). The largest differences between both modes is that in "meta-types allowed" mode:

• simple copies are created (via exactReplica) instead of proper ones
• expressions in types (ranges, dependent types, etc.) are skipped
• no types are committed to the instantiation cache
• interaction with ModuleGraph state (e.g., hooks) is disabled

A different way to look at the "allow meta-type" mode is that it allows for replacing type variables while some of them may be still unknown.

Two problems that arise from this:

1. there a two paths through semtypinst, which makes the code very non-linear, and thus hard to follow
2. the types coming out of semtypinst in "meta-types allowed" are improper ones, whose presence complicates other things (for example, the sameObjectType logic, which now can't rely on ID comparisons)

The reason for meta-tyGenericInst types existing seems to mainly be for the convenience of typeRel, which lacks proper support for unapplied tyGenericInvocations (a tyGenericInst is effectively an evaluated tyGenericInvocation).

Concrete benefits

Not having the "allow meta-type" mode would significantly simplify the logic in semtypinst and make the code easier to reason about. In addition:

• tyGenericInst would change to always represent fully resolved non-meta types
• while some exactReplica usages are likely going to be still required, a lot of them can removed

Both, in turn, would either help with or make possible further improvements to semtypinst and other type-related fixes.

How?

Removing the "meta-types allowed mode" will first require moving all of its users. These are (in no specific order):

• instGenericContainer usage when turning a tyGenericBody into a tyCompositeTypeClass. Done: internal: keep composite type-classes unresolved #864
• instGenericContainer usage for instantiating generic concepts. Done: internal: don't instantiate concepts when lifting types #861
• prepareMetatypeForSigmatch in tryGenerateInstance. Done: internal: improve tryGenerateInstance #858
• prepareMetatypeForSigmatch in typeRel. Done: typerel: rework tyGenericInvocation handling #854
• replaceTypesInBody in tryResolvingStaticExpr. Done: better dependent-expression support for range types #850

Many of the aforementioned boil down to duplicating and adjusting the relevant replaceTypeVarsT and handleGenericInvocation parts into standalone procedures.

[zerbina]

All the users of the "meta-types allowed" mode are now removed. I'll make a PR that removes the mode itself and after that focus on cleaning up / reworking semtypinst.