+ refactoring: account for Bivariance
 + refactpring: collect variance related ops in Variances,
   move Variances to core.

This is meant as a better alternative to encode variances in parameter names.

Encode them instead in the upper bound lambda of a TypeBounds type.

For now, we also encode them in the alias of a Typealias type, but
this will be dropped one we pass to structural lambda variance.

The old encoding using semantic parameter name is still in place. The
new recording inside TypeBounds exists alongside the old one.

Needs to be passed as a parameter since Namer does not construct
a bounds immediately.

These can hopefully be revived once the variance changes have completed

... unless they are on the right hand side of type bounds or
match aliases or they are type aliases where some variance is
given explicitly with a `+` or `-`.

This reverts commit 7d6e75e.

Type lambdas don't print with variances anymore

Since variances are associated conceptually with higher-kinded type variables,
it makes no sense to write them on type lambdas. I believe it's better to disallow
writing variances there because it will only need to variance-bike-shedding otherwise.

A refinement type would previously qualify as an `isRef` of
Any, AnyKind, or AnyRef. Often that is not what was intended.
Break out `isAny`, `isAnyKind`, and `isAnyRef` methods for
tests that don't go through refinements.