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-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.
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
Dotless type application for infix operators.

When you have an aesthetic expresion like

  def f(xs: Iterator[Int]) = (
    xs takeWhile (_ < 1000)
             map (_ * -1)
          filter (_ % 2 == 0)
         flatMap (x => List(x, x))
    reduceOption (_ + _)
           maxBy (_.toString)
  )

And then for whatever reason you have to perform explicit
type application in the midst of that expression, it's
aggravating in the extreme that it has (had) to be rewritten
in its entirety to accommodate that change.

So now you can perform type application in the middle of it.

For reasons not entirely clear to me postfix operators are
excluded. The discussion as well as the approval for the infix
variation of it can be found at:
  https://groups.google.com/forum/#!msg/scala-language/eJl1wnkEz9M/hR984-lqC5EJ
Remove the unused test.continuations.suite.
Remove spurious resurrection of src/swing.
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.