Allow supertypes of parameterized types

[nsbgn]

At the moment, parameterized types can only have sub- and supertypes by automatic extension of their parameters' sub- and supertypes. For example, if A <= B, then F(A) <= F(B).

However, it may sometimes be useful to have these types themselves be part of a hierarchy. Broadly, I see the following approaches:

1. Allow a parameterized type to have a single, non-parameterized supertype. As in, A = TypeOperator() and F = TypeOperator(params=2, supertype=A).
2. Allow a parameterized type to have a single parameterized supertype of the same arity. As in, F = TypeOperator(params=2) and G = TypeOperator(params=2, supertype=F).
3. Allow a parameterized type to have an arbitrary supertype.

The use case demonstrated by @simonscheider and @EJTop today (cf https://github.com/quangis/ratios) was to have both ArchimedeanMagnitudes and ProportionalMagnitudes be Magnitudes. This corresponds to option 1. Intuitively, I also think the this one makes most sense. Mixing them would almost certainly be a bad idea.

However, I haven't throught through the implications in terms of the inference. In the meantime, it is possible to emulate such a type by using a TypeAlias with an EliminationConstraint --- the pseudo-supertype A would be interpreted as either one of its parameterized subtypes. So, instead of this:

A = TypeOperator()
F = TypeOperator(params=1, supertype=A)
G = TypeOperator(params=1, supertype=A)

You would do this:

F = TypeOperator(params=1)
G = TypeOperator(params=1)
A = TypeAlias(TypeSchema(lambda x: x [x << {F(_), G(_)}]))

Inferences would then be subtly different. Other relevant issues:

• Union types (Union types (explicit overloading) #106). F(_) & G(_) would be another variant.
• Inclusion of aliases in vocabulary (Source reuse may cause type mismatches #110). If a supertype is emulated via a type alias, you probably want them to show up in the generated type taxonomy.
• Nested constraints (Nested constraints #86).