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-8052 Disallow `macro` as an identifier

Note that the change could look a lot cleaner, at the cost of returning
more generic error messages. I decided that at least for 2.11 I'll keep
scalac remembering that macro was a standard identifier name once, so
that we can point out more precisely what's wrong with users' code.
SI-8046 Fix baseTypeSeq in presence of type aliases
Pending test for SI-6161

Not solved with base type dealiasing
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.
typeCheck => typecheck

This method has always been slightly bothering me, so I was really glad
when Denys asked me to rename it. Let’s see how it pans out.
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.
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.
SI-7850 CCE in patmat with invalid isEmpty.

Name-based pattern matcher needed some hardening against
unapply methods with the right name but wrong types. Only
isEmpty methods which return Boolean are acceptable.
Catching it directly rather than indirectly also allowed
for better error messages.
removing defensive code made obsolete by existing fix to SI-5604

SI-5604 was fixed in commit e6f10b07d44f0ddde26246b4a41527a84eede81c
overzealous assert in BCodeBodyBuilder rejected throw null
SI-8047 change fresh name encoding to avoid owner corruption

Previously a following encoding was used to represent fresh
names that should be created at runtime of the quasiquote:

  build.withFreshTermName(prefix1) { name$1 =>
    ...
      build.withFreshTermName(prefixN) { name$N =>
        tree
      }
    ...
  }

It turned out that this encoding causes symbol corruption when
tree defines symbols of its own. After being spliced into anonymous
functions, the owner chain of those symbols will become corrupted.

Now a simpler and probably better performing alternative is
used instead:

  {
    val name$1 = universe.build.freshTermName(prefix1)
    ...
    val name$N = universe.build.freshTermName(prefixN)
    tree
  }

Here owner stays the same and doesn’t need any adjustment.
Use t- prefix instead of si- prefix for test files