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.
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.
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.
Fix typo in scala-library-all-pom.xml.
Always copy man/* and doc/tools/*.
Explicit jline dependency.

Duplicated from scala-compiler's pom (where it's optional),
so that resolving scala-dist's transitive dependencies include jline.
We won't see scala-compiler's optional dependency on jline when depending on
scala-compiler.

TODO: remove duplication once we have the scala-compiler-repl module
SI-8045 type inference of extracted value

Test case for SI-8045, fixed by the preceding commits.
SI-7443 Use typeclass instance for {Range,NumericRange}.sum

Previously both Range and NumeriRange used formula for sum of elements
of arithmetic series and thus always assumed that provided Numeric is
regular one.
Bug is now fixed by conservatively checking if Numeric is one of
default ones and the formula still holds.
Eliminated some dead/redundant code based on review.
Finalized some case classes, for better static checking.
SI-6364 SetWrapper does not preserve performance / behavior

O(n) performance of wrapped set contains was the problem.

Added overrides for contains and isEmpty to SetWrapper.  Note that sets are
invariant in Scala, while the Java signature is for any Object, so we trap
a ClassCastException if one occurs.  (Is this everything that could possibly
go wrong?  I think so, but am not as confident as I would like.)