Fix isStructuralTermSelectOrApply

[odersky]

When looking at AppliedTypes, we want to go to the supertype (which is the dealiased type or upper bound),
not the underlying type (which is the type constructor).

This is the second bug in a week caused by a confusion of underlying and supertype for AppliedTypes. We
should do an audit of the codebase to see whether there are more cases like this.

Fixes #15448

[odersky]

@KacperFKorban If we can get this reviewed today, it could still be part of 3.2.

[odersky]

How I fixed it:

The original example was quite complex. I reduced it a bit to the one in the "pos" test case of this commit. I then changed the opaque type to a normal type alias and verified that it did compile. I looked at the code after erasure and saw that it generated a conversion to Selectable followed by a call to applyDynamic in the case of a normal alias, but it generated none of that in the case of an opaque alias, which caused the crash in erasure.

I then took the compiling example and compiled it with -Yshow-tree-ids to find out where the necessary code was generated. I added -Ydebug-tree-with-id with one of the node ids in the generated code. That showed me a stack trace where the node was copied, which is unfortunately quite often the case, and which would require further instrumentation in the copier. (In fact that's a case that would be worthwhile to automate: re-run with id of original tree that got copied repeatedly until you hit the originally constructed tree). In my concrete case I found another node (the result of the implicit conversion) that was not copied, and that got me an informative stack trace. It showed that the tree was generated in adapt1, following a test isStructuralTermSelectOrApply. Further instrumentation showed that the hasRefinement test in isStructuralTermSelectOrApply was true for normal aliases but false for opaque aliases. I then looked at the logic. The opaque alias was upper bounded by a refined type as argument, why did it not find that refinement? Then it became clear. The reference to the opaque alias was an AppliedType, and we followed its underlying field, which gives us the type constructor. But we need the full upper bound, which is reached by superType instead.

In the meantime Kacper had minimized the example even more, this time to an example that should not compile. I added that as a neg test.