WIP: Keep skolem types when unpickling/bringing a denotation to a new run, in more cases

[jchyb]

Attempts to fix #22585

The source of the issue is in the inlined makeHammer method, where the hammer method Is generated.
Initially, hammer.hammer(???.asInstanceOf).asInstanceOf[O] Is typed as

<
  {
    <
      <
        <
          <
            <<this:($anon.this : Object with Hammer[Any, Any] {...})>.
              hammer:(=> Hammer[?, Int])>
          .hammer:((input: <?1:Hammer[?, Int]>.I): Int)>
        (
          <<<???:(=> Nothing)>.asInstanceOf:([X0]: X0)>[
            <?1:Hammer[?, Int]>.I]:<?1:Hammer[?, Int]>.I>
        ):Int>
      .asInstanceOf:([X0]: X0)>
    [Any]:Any>
  }
:Any>

So hammer.hammer is a function with a skolemtype ((input: <?1:Hammer[?, Int]>.I): Int) and ???.asInstanceOf is the same skolemtype (<?1:Hammer[?, Int]>.I>).

The issues arrived when we either would try to inline this from unpicked tasty (test case tests/pos/i22585-a), or if we suspended compilation (e.g. because of a macro method usage) and tried to inline it in a new run, after compiling the inlined method.

In the first case, we would previously not unpickle the applied type parameter to ???.asInstanceOf to a skolemtype, (but the function input would) so a type checker would fail there.
In the second case, we would remember the skolemtype in the ???.asInstanceOf, but the hammer.hammer function denotation, while being brought to a new run, would recalculate the type, losing the skolemtype in the process (and then failing the type checking).

This PR currently provides naive fixes to both things, but the unpicking part seems to suffer from a few issues:

• Expectations for java tasty are not being uphold (we unpickle legal stable java paths into skolem types).
• Some errors related to incremental compilation appear on the CI (although I was not able to reproduce them locally yet)