More aggressive reduction of type selection (fixes parboiled2)

[smarter]

Previously, when reducing a.T we checked if the type of a was a subtype of
RefinedType(.., T, TypeAlias(...)), now we extend this check to handle
refinements where the info is a TypeBounds where both bounds are equal.

This solves two big issues at once:

• We can restore tests/pos/13491.scala to its original form from before Don't follow BaseType of abstract binders in MT reduction #13780.
  The check for abstract types introduced by Don't follow BaseType of abstract binders in MT reduction #13780 for soundness reasons is no
  longer hit because the type selection is reduced before we get to that point.
  This is important because parboiled2 relies on this and is therefore currently
  broken on 3.1.3-RC1 and main (Compilation broken against current dotty nightlies and likely for upcoming Scala 3.1.3 sirthias/parboiled2#365).
• This fixes Slow compilation with chained dependent match types  #14903 (slow compilation issue affecting parboiled2) without
  caching skolems (as in the alternative fix Cache skolem types #14909). Again, this is due to the
  type containing skolem being reducible to a simpler type and therefore cacheable.

[smarter]

test performance please

[dottybot]

performance test scheduled: 6 job(s) in queue, 1 running.

[smarter]

If this is accepted, I think it's worth backporting to 3.1.3 since it fixes a regression and would benefit parboiled2 as well as downstream libraries like akka-http, wdyt?

[smarter]

I think the root of the confusion here is the definition of toBounds:
https://github.com/lampepfl/dotty/blob/119e3d76a5b4476d1e0cfc282bb81d163d0de7cd/compiler/src/dotty/tools/dotc/core/TypeApplications.scala#L410-L416
self.isMatch will return true for the rhs of Out in https://github.com/dotty-staging/dotty/blob/aggressive-reduction/tests/pos/i14903a.scala#L15 because the rhs is an applied match type, even though Out itself is just a plain type alias, so we end up typing it as a MatchAlias. Perhaps toBounds should check if the rhs tree is a MatchTypeTree instead? But then I don't know what to do about the unpickling logic for MatchAlias which also relies on the type of the alias itself: https://github.com/lampepfl/dotty/blob/119e3d76a5b4476d1e0cfc282bb81d163d0de7cd/compiler/src/dotty/tools/dotc/core/tasty/TreeUnpickler.scala#L374-L377
Maybe we need to actually store whether we're pickling a MatchAlias or TypeAlias in Tasty? But that fix wouldn't be backportable to 3.1.x

[dottybot]

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/14987/ to see the changes.

Benchmarks is based on merging with main (119e3d7)

[odersky]

LGTM. I think that was an overlook when MatchAliases were introduced to not also consider them in lookupRefined.