Before 1.11, the body of `JSConstructorDef`s was a straight list of
trees. We have a hack that extracts the three parts of a structured
`JSConstructorBody`: `beforeSuper`, `superCall` and `afterSuper`.

In 1.18, we introduced a separate hack to ensure that `afterSuper`
starts with a `StoreModule` instruction.

Unfortunately, we did not apply the latter hack on the result of
the former. This means our deserializer incorrectly reads JS module
classes from before 1.11.

This commit makes sure to also apply the hack in that situation.

Unfortunately, this does not come with automated tests. We do not
have any non-native JS module class in our standard library, which
is currently our only source of old IR for backward compatibility
tests.

Upgrade to Scala 2.12.20 and 2.13.16.

Under 4 cases, some versions of the compiler do not emit a switch
match. That defeats the purpose of that test.

That shape gets produced by Scala 2.13.16+ in some cases.

Previously, we had to recognize specific shapes of case bodies in
order to extract jumps to default labels. This was fragile, as
changes in nsc's codegen could invalidate our assumptions.

We now take a more general approach. We register the default label
in the `enclosingLabelDefInfos`. Jumps to that label can therefore
be handled wherever they appear inside the case bodies.

We still require a specific shape to extract the *definition* of
the default label in the wildcard case. This can't be helped, as
far as I can tell.

Ultimately, the JS code generated for the test suites is unchanged,
both in 2.12 and 2.13.

Somehow it had always escaped us that we did not correctly perform
that optimization in Scala 2.13.

…from-1.8

Fix #5115: Apply the StoreModule hack to JSConstructorDef from 1.8.

Fix #5112: Recognize asInstanceOf around jump to default label.

Optimize the shapes of `js.Dynamic.literal()` in Scala 2.13.