Marginally better LUB for different instantiations of the same interface.

[lrhn]

Currently Up(T1, T2) recognizes if T1 is C<S1,..,Sn> and T2 is C<R1,...,Rn>, with some Si != Ri, and tries to unify the type parameters.
However if T1 implements C<S1,...,Sn> and T2 implements C<R1,...,Rn>, then we may fall through to the old depth-based LUB algorithm, which only looks at common types between the two types, and C<S1,...,Sn> is a different type than C<R1,...,Rn>, so neither gets included in the comparison.

I suggest that we reconsider that approach. When looking for common supertypes, we'll find C1<S1,...,Sn> and C1<R1,...,Rn> has the same depth, but are not equal. We should then realize that they are related, and if one is a supertype of the other (and not vice versa), then we do include the supertype in the set of common supertypes. (It can still fail to be the LUB if there are other candidates at that depth. Which means that this change may break existing code that relied on another supertype of the same depth being the only one.)

That is, in the step where we collect all common superinterface of two types and group them by depth, and then intersect the sets, the intersection should not just do "same type" checks, but retain an interface if the other set contains an instantiation of the same generic interface with an instantiation that is a proper subtype.

Concretely I'm trying to add a type parameter to Pattern, so that Pattern<M extends Match> has methods returning M, and then RegExp implements Pattern<RegExpMatch>.
My problem is that ["a", RegExp("b")] used to be inferred as List<Pattern>, but with the type parameter, it is inferred as List<Object> because Pattern<Match> and Pattern<RegExpMatch> are considered completely unrelated.

(We can probably do much better if we built a LUB from scratch, but this particular change seems within reach and still able to do something good in some cases.)

@stereotype441