Fix improper usage of constrained breaking type inference

[smarter]

In multiple places, we had code equivalent to the following pattern:

val (tl2, targs) = constrained(tl)
tl2.resultType <:< ...

which lead to subtype checks directly involving the TypeParamRefs of the
constrained type lambda. This commit uses the following pattern instead:

val (tl2, targs) = constrained(tl)
tl2.instantiate(targs.map(_.tpe)) <:< ...

which substitutes the TypeParamRefs by the corresponding TypeVars in the
constraint. This is necessary because when comparing
TypeParamRefs in isSubType:

• we only recurse on the bounds of the TypeParamRef using
  isSubTypeWhenFrozen which prevents further constraints from being
  added (see the added stm.scala test case for an example where this
  matters).
• if the corresponding TypeVar is instantiated and the TyperState has
  been gc()'ed, there is no way to find the instantiation corresponding
  to the current TypeParamRef anymore.

There is one place where I left the old logic intact:
TrackingTypeComparer#matchCase because the match type caching
logic (in MatchType#reduced) conflicted with the use of TypeVars since
it retracts the current TyperState.

This change breaks a test which involves an unlikely combination of
implicit conversion, overloading and apply insertion. Given that there
is always a tension between type inference and implicit conversion, and
that we're discouraging uses of implicit conversions, I think that's an
acceptable trade-off.