Reset GADT constraint on failing isSubType

[odersky]

The normal constraint gets reset when isSubType fails - should the GADT constraint
not get reset as well? Subtyping is an exploration with backtracking where
some branches do not lead to a result. It seems unsound that failing explorations
can nevertheless introduce new GADT bounds.

I tried to change this in this commit, but it makes the following tests
fail with stack overflows:

tests/pos/i9740b.scala failed
tests/pos/i9740c.scala failed

I must admit I am not quite sure about whether it is enough to reset just the constraint
part of a GadtConstraint, or whether the whole constraint has to be copied. I hope not the
latter, since that would impose a heavy complexity price on subtype checking.

[odersky]

@abgruszecki Can you comment and if necessary continue with this PR?

[odersky]

I think the understanding of GADT handling could be improved by aligning terminology. A GADTConstraint is really more like a ConstraintHandler than a Constraint since Constraints are immutable. The mutability of GADTConstraints seems to have some negative consequences when it comes to backup and restore. Can we make GADTConstraints immutable as well?

[abgruszecki]

tests/pos/i9740b.scala fails with strange errors, but it seems that the errors themselves aren't incorrect:

-- [E007] Type Mismatch Error: tests/pos/i9740b.scala:10:9 -------------------------------------------
10 |    case UnitExp =>
   |         ^^^^^^^
   |         Found:    UnitExp.type
   |         Required: Exp[A]
   |
   |         where:    A is a type in method bar with bounds <: T
   |
   |         pattern type is incompatible with expected type

With this change, we now detect that the pattern is incompatible with the scrutinee, since it requires that Unit <: A <: T <: U <: Int, which cannot be the case.

tests/pos/i9740c.scala, OTOH, does fail with stack overflow errors. I'll have to take a closer look.