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.
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.
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
Remove the unused test.continuations.suite.
Remove spurious resurrection of src/swing.
SI-7492 Make scala.runtime.MethodCache private[scala]

These are internal implementation details which shouldn't be exposed
to users (and might go away when support for invokedynamic is added).
SI-7680 Update the ScalaDoc entry page of the Scala library
Prepare maven-based distribution building.

NOTE: `maven/latest/build.xml` is now deprecated.

To publish a Scala build, simply call `ant publish` or `ant publish-local`.
`maven/latest/build.xml` will soon disappear from `dists/`

The idea is that a Scala distribution is a simple
repackaging of artifacts already available on maven.

Already available: typical jars for the artifacts (classes, sources, scaladoc).
To add: the bin/, doc/, and man/ directories.

Thus, move the contents that should end up in the distribution
from docs/ to doc/, create the man/ directory with the manpages,
and include the scripts in bin/.

Next up: package these directories in a jar and publish to maven,
with a dependency on scala-library-all, scala-reflect and scala-compiler,
for the jars that should end up in the distribution.

Refactorings:
 - Pull filter-pom out from deploy-one.
 - Rename maven-base to dist.maven.
 - Set all properties in the init target (dist.maven)
scala-dist: all you need to roll your own scala distribution

We now publish a scala-dist artifact every time we publish to maven.
It captures everything needed to build a Scala distribution.

The packager should resolve all transitive dependencies of scala-dist,
put the class-file jars in the lib/ directory,
the scaladoc jars in the api/ directory,
and the source jars in the src/ directory,
in addition to unpacking the scala-dist jar itself,
which contains the bin/, doc/ and man/ directories,
which previously weren't available on maven.

This also removes the `@{dir}` abstraction, which was used to
package the continuations plugin. Since it's moved out,
we can go back to hard-coding it.
scala-library-all: dependency for those who want it all

If you'd rather depend on all Scala has to offer, module-wise,
depend on scala-library-all. This dependency determines the
jars that ship with the Scala distribution. To achieve parity
via maven resolution, this is the artifact to depend on.