Make translucentSuperType handle match types

[odersky]

This fixes several erasure related things, such as signature, or erasure itself.

Fixes #8666
Fixes #7894

[odersky]

Note: This is technically a binary incompatible change since it causes bridge methods to be created where none were created before. On the other hand, I have a hard time thinking of an example that compiled before and now compiles with different binary signatures.

[sjrd]

This is technically a binary incompatible change since it causes bridge methods to be created where none were created before.

If it's only bridges, and only added, then it's only forward binary incompatible; it's backward compatible.

[smarter]

I played a bit with it and couldn't find a binary- or tasty-incompatible difference either (but I have to say that I don't really understand in what situations we do or don't normalize match types).

[smarter]

Why do this in translucentSuperType and not superType? At the very least it means the documentation of the base translucentSuperType in https://github.com/lampepfl/dotty/blob/f618dd66a93a962c99c22eb586dbc93d7d410988/compiler/src/dotty/tools/dotc/core/Types.scala#L1891-L1892 is now incorrect.

[odersky]

I fixed the comment, which now also explains why we can't do it in superType.

[odersky]

As far as I can see we did not normalize match types when computing the signatures and erasures of inherited members. That means we did not detect logical overrides, and that means we did not generate bridges where they would have been necessary.

Match types that can be reduced directly in signatures were reduced. For instance in

  type M[X] = X match
    case Int => String
    case _ => X

  def test(x: M[Int]): Int = ???

the signature of test is String => Int.

[liufengyun]

This PR has a big impact on performance when compiling stdlib:

http://dotty-bench2.epfl.ch/

[odersky]

I tracked it down to match type simplification for tuples, and it seems in particular provablyDisjoint.