internal: keep composite type-classes unresolved

[zerbina]

Summary

Change composite type-classes (tyCompositeTypeClass) to store an
unresolved type application (tyGenericInvocation) instead of a fully
resolved and instantiated meta-type (tyGenericInst). This removes the
last usage of semtypinst's "meta-types allowed" mode, meaning that
the latter can be removed now.

As part of the change, a type relation bug is fixed: generic
instantiations were incorrectly treated as having a 'generic'
relationship with composite type-classes of different generics that had
the same structure. For example, A[int] is B returned 'true' when
A[T] = (T,) and B[T] = (T,).

Details

• update the documentation of tyCompositeTypeClass
• in type lifting (liftParamType), don't resolve the invocation lifted
  from the tyGenericBody, but instead store the invocation in the
  tyCompositeTypeClass directly
• update typesrenderer to render a tyCompositeTypeClass as the
  original type expression (which is stored in the first slot)
• partially resolve the invocations stored in tyCompositeTypeClass
  when skipping them during .borrow handling, approximating how
  the skipped type would have looked previously

Parametric aliases of parametric concepts

• support non-lifted invocations of parametric user type-classes
  (concept) with matchUserTypeClass
• in typeRel, dispatch to matchUserTypeClass when matching against
  such invocations

Invocations of parametric concepts without arguments are lifted into
tyUserTypeClassInst instead of tyCompositeTypeClass, but for
parametric aliases of parametric concepts (e.g.,
Type[T] = Concept[T] where a Concept is a parametric concept), this
is not case, meaning that tyGenericInvocations where the body is a
tyUserTypeClass reach typeRel.

Parametric aliases of parametric concepts in the composite type-class
case were previously handled by way of them being resolved to
tyUserTypeClassInst as part of instGenericContainer, but without the
latter, they now need to be handled in typeRel, which is what changes
detailed above implement.

However, there is a problem. A tyUserTypeClassInst can bind types
for later retrieval, while a tyGenericInvocation cannot. While a
solution is going to be needed at some point, no user-facing regression
is introduced with the changes here, as tyCompositeTypeClass types in
routine signatures act as type variables (they're replaced with their
bound type during instantiation) and for conversions-to-composite-type-
classes (e.g., Generic(x)), the type bound to the resolved
tyUserTypeClassInst was already ignored previously.

Type relation changes

The typeRel logic for tyCompositeTypeClass is changed back to how it
was prior to e97d640, which is both
now-necessary (for proper matching against a tyGenericInvocation's)
and fixes a type relation bug. By skipping the first instance, that
commit changed generic instantiation to be treated as having a 'generic'
relationship with different but structurally equal generic types, which
seems to have been an unintended side-effect. A test is added for the
fixed behaviour is added.

Coercions to distinct generic types are kept working by allowing generic
instances to be matched against the partially-resolved body of a
generic distinct type -- if coerceDistincts is 'false', the call to
typeRel with formal = tyDistinct is going to return isNone.

[saem]

The new behaviour where different generic types don't match makes sense, it's not very clear when we should use nominal vs structural matching and the nominal behaviour is a good default.

I'm really glad to see the meta types allowed mode being dropped. 🚀

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• wraps up removing users of semtypinst's "meta-types allowed" mode
• I'm going to remove the "meta-types allowed" mode of semtypinst in a separate PR