SI-2066 Plug a soundness hole higher order type params, overriding

PolyType-s parameterized by higher order type parameters (HOTPs)
should only be relatable with <:< or =:= if the variances of their
type parameters line up. This is only enforced for HOTPs defined in
method type arguments.

Invariant type parameters subsume variant ones. Concretely, as
described by @S11001001:

> A method taking [F[_]] can implement a method taking [F[+_]].
> Likewise, a method taking [F[_[+_]]] can implement a method
> taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]],
> and so on, the variance subsumption flipping at each step.
>
> This is just the opposite of the variance for passing type
> parameters to either instantiate types or call methods; a F[+_]
> is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument,
> and so on.
>
> All of the above rules can be duplicated for contravariant positions
> by substituting - for +. Also, something similar happens for
> weakening/strengthening bounds, I believe.

These cases are tested in the `// okay` lines in `neg/t2066.scala`.
SI-8046 Fix baseTypeSeq in presence of type aliases
Pending test for SI-6161

Not solved with base type dealiasing
SI-8062 Fix inliner cycle with recursion, separate compilation

ICodeReaders, which decompiles JVM bytecode to ICode, was not
setting the `recursive` attribute of `IMethod`. This meant that
the inliner got into a cycle, repeatedly inlining the recursive
call.

The method name `filter` was needed to trigger this as the inliner
heuristically treats that as a more attractive inlining candidate,
based on `isMonadicMethod`.

This commit:

  - refactors the checking / setting of `virtual`
  - adds this to ICodeReaders
  - tests the case involving `invokevirtual`

I'm not sure how to setup a test that fails without the other changes
to `ICodeReader` (for invokestatic and invokespecial).
SI-8046 Only use fast TypeRef#baseTypeSeq with concrete base types

We can only compute the base type sequence (BTS) of a `TypeRef` by
element-wise transforming the BTS of the referenced symbol if
there are no abstract types in its BTS type symbols.

In the now-working test case, `pos/t8046.scala`, the difference
between the old and new calculation of the BTS is:

    this                 = Three.this.Alias[Int]
    sym.info.baseTypeSeq = BTS(One.this.Op[A],Any)
    mapped BTS           = BTS(Three.this.Op[Int],Any)
    full BTS             = BTS(Three.this.Op[Int],Int => Int,Object,Any)

The change to account for PolyType in ArgsTypeRef#transform is now
needed to avoid the full BTS of:

    BTS(Three.this.Op[A],A => A,Object,Any)

Interestingly, everything actually works without that change.
Revert "SI-6426, importable _."

This reverts commit d2316df920ffa4804fe51e8f8780240c46efa982.

We can't make `_` an illegal identifier -- it's legal in Java,
so we must be able to name these Java underscores.
Merge pull request #3253 from retronym/ticket/8062

 Fix inliner cycle with recursion, separate compilation
Merge pull request #3261 from adriaanm/ticket-6426

Revert ", importable _."
Partially revert f8d8f7d08d.

Need `${dist.dir}/lib/scala-partest.jar` for maven publish.

We still don't want to distribute it in the distribution,
but will have to remove it in release script, as 2.10.x's
build hasn't been refactoreded like master's, and I'm not backporting it.
Presentation compiler hyperlinking on context bounds test

Added test to the presentation compiler regression suite to exercise
hyperlinking on context bounds.
SI-4287 Added test demonstrating hyperlinking to constructor's argument

This test was inspired by `test/files/run/t5603`, whose output (.check file)
will need to be updated in the upcoming commit that fixes SI-4287, because
the positions associated to the tree have slightly changed.

The additional test should demonstrate that the change in positions isn't
relevant, and it doesn't affect functionality. In fact, hyperlinking to a
constructor's argument work as expected before and after fixing SI-4287.
SI-4827 Test to demonstrate wrong position of constructor default arg

As demonstrated by the attached test, hyperlinking on constructor's
default arg doesn't work (the returned tree is the parameter tree,
i.e., `f`, which is of course wrong).

Printing the tree reveals the issue:

``
[[syntax trees at end of                     typer]] // Foo.scala
[0:63]package [0:0]<empty> {
  [0:37]class Baz extends [9:37][39]scala.AnyRef {
    [10:31]<paramaccessor> private[this] val f: [14]Int = _;
    [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
    [39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{
      [39][39][39]Baz.super.<init>();
      [9]()
    }
  };

  [6]<synthetic> object Baz extends [6][6]AnyRef {
    [6]def <init>(): [9]Baz.type = [6]{
      [6][6][6]Baz.super.<init>();
      [9]()
    };
    [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
  };
  [39:63]object B extends [48:63][63]scala.AnyRef {
    [63]def <init>(): [48]B.type = [63]{
      [63][63][63]B.super.<init>();
      [48]()
    };
    [52:61]private[this] val a: [56]Int = [60:61]2;
    [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
  }
}
``

In short, the default argument in `<init>` (the constructor) has an
offset position, while we would expect it to have a range position.
Therefore, when locating a tree for any position between (start=) 10
and (end=) 31, the paramaccessor tree `f` is returned.

The next commit will correct the problem.
Report error on code size overflow, log method name.

We used to silently skip class files that would exceed the JVM's size limits.
While rare, this should still be an error.

While I was at it, also included the name of the offending method.
Merge pull request #3268 from adriaanm/support-3021

Report error on code size overflow, log method name.
GenBCode version of "Updating Position call sites" commit

7d62df035cd4393c73e7530e1cad1130e79d90c6 modifies GenASM, we follow suite here.
GenBCode version of "not eliminate loadmodule on static methods."

f27f2d80d759130597b652d6cc9d789f8c472e5a modifies GenASM, we follow suite here,
making test/files/run/static-module-method.scala pass under GenBCode.
there's a reason for this code in GenBCode

aced32d05c97651534f468bc9a475ea5f6ae75b8 removed unused code,
along with code that populates a cache with entries needed
in some program runs. I'm re-adding the latter.
removing dead code in BCodeSyncAndTry
overzealous assert in GenBCode

The assert in question was aimed at ruling out
gotos (ie "jumping-applys") in actual argument position
of a jumping-apply.

But the assert in question went overboard
to also rule out a LabelDef in actual argument position.

This commit removes the assert in question altogether.

The unwanted behaviors, and only those, are rule out by
the test added in this commit and the existing tests for SI-6089.

See also https://issues.scala-lang.org/browse/SI-7749
SI-7897, SI-6675 improves name-based patmat

This emerges from a recent attempt to eliminate pattern matcher
related duplication and to bake the scalac-independent logic
out of it. I had in mind something a lot cleaner, but it was
a whole lot of work to get it here and I can take it no further.

Key file to admire is PatternExpander.scala, which should
provide a basis for some separation of concerns.

The bugs addressed are a CCE involving Tuple1 and an imprecise
warning regarding multiple pattern crushing.

Editorial: auto-tupling unapply results was a terrible idea which
should never have escaped from the crib. It is tantamount to
purposely throwing type safety down the toilet in the very place
where people need type safety the most. See SI-6111 and SI-6675 for
some other comments.