Upstreaming: Eliminate parameter contravariance

[cpovirk]

ff45ce7

As noted in that commit, we may end up wanting to support it after all.

If so, then we have a different task ahead of us: Figure out if CF's behavior for "the Ordering.min/max case" (discussed in the commit message) qualifies as a bug, and either make CF's logic accommodate our subtyping logic or make our subtyping logic work around what it needs to.

And actually, we might need to do one of those anyway: It might be possible to produce a new failure in our prototype checker by changing the code to compare E[] and F[] using a subtype check instead of an equality check. Presumably we'd do that by writing a sample that uses the return type instead of a parameter.

It may be that the CF difficulty is here:

https://github.com/typetools/checker-framework/blob/fd0abaa8b8fea775aaf71057d93d9415355b665e/framework/src/main/java/org/checkerframework/framework/type/AnnotatedTypeMirror.java#L1387

CF calls createType, but it probably it is not "adapting the formal parameter types of N to the the type parameters of M." (It's probably also not applying defaulting rules -- a separate issue that may also be worth a look at some point.)

[cpovirk]

Hmm, or maybe the CF code could do the "adapting" step as long as asMemberOf eagerly initialized the component type at that point and then updated it? But it looks like it might not be updating it at all, regardless of whether it was already initialized:

https://github.com/typetools/checker-framework/blob/fd0abaa8b8fea775aaf71057d93d9415355b665e/framework/src/main/java/org/checkerframework/framework/util/AnnotatedTypes.java#L443

[cpovirk]

I ended up undoing part of my original change in 3ad2137 (for reasons of method references, discussed in the commit message).