SI-6937 core type tags are no longer referentially unique

Type tag factory used to evaluate the provided type creator in the
context of the initial mirror in order to maintain referential equality
of instances of standard tags. Unfortunately this evaluation might fail
if the mirror provided doesn't contain the classes being referred to.
Therefore I think we should avoid evaluating type creators there.

Note that failure of evaluation doesn't mean that there's something
bad going on. When one creates a type tag, the correct mirror /
classloader to interpret that tag in might be unknown (like it happens
here). This is okay, and this is exactly what the 2.10.0-M4 refactoring
has addressed.

Something like `res2.typeTag[A].in(currentMirror)` should be okay.
Revert "SI-6387 Clones accessor before name expansion"

This reverts commit 4e10b2c833fa846c68b81e94a08d867e7de656aa.

Add 6387 test to pending and 7341 to up-to-date.
SI-7289 Less strict type application for TypeVar.

When a type constructor variable is applied to the wrong number of arguments,
return a new type variable whose instance is `ErrorType`.

Dissection of the reported test case by @retronym:

Define the first implicit:

    scala> trait Schtroumpf[T]
    defined trait Schtroumpf

    scala> implicit def schtroumpf[T, U <: Coll[T], Coll[X] <: Traversable[X]]
         |     (implicit minorSchtroumpf: Schtroumpf[T]): Schtroumpf[U] = ???
    schtroumpf: [T, U <: Coll[T], Coll[X] <: Traversable[X]](implicit minorSchtroumpf: Schtroumpf[T])Schtroumpf[U]

Call it explicitly => kind error during type inference reported.

    scala> schtroumpf(null): Schtroumpf[Int]
    <console>:10: error: inferred kinds of the type arguments (Nothing,Int,Int) do not conform to the expected kinds of the type parameters (type T,type U,type Coll).
    Int's type parameters do not match type Coll's expected parameters:
    class Int has no type parameters, but type Coll has one
                  schtroumpf(null): Schtroumpf[Int]
                  ^
    <console>:10: error: type mismatch;
     found   : Schtroumpf[U]
     required: Schtroumpf[Int]
                  schtroumpf(null): Schtroumpf[Int]
                            ^

Add another implicit, and let implicit search weigh them up.

    scala> implicitly[Schtroumpf[Int]]
    <console>:10: error: diverging implicit expansion for type Schtroumpf[Int]
    starting with method schtroumpf
                  implicitly[Schtroumpf[Int]]
                            ^

    scala> implicit val qoo = new Schtroumpf[Int]{}
    qoo: Schtroumpf[Int] = $anon$1@c1b9b03

    scala> implicitly[Schtroumpf[Int]]
    <crash>

Implicit search compares the two in-scope implicits in `isStrictlyMoreSpecific`,
which constructs an existential type:

   type ET = Schtroumpf[U] forSome { type T; type U <: Coll[T]; type Coll[_] <: Traversable[_] }

A subsequent subtype check `ET <:< Schtroumpf[Int]` gets to `withTypeVars`, which
replaces the quantified types with type variables, checks conformance of that
substitued underlying type against `Schtroumpf[Int]`, and then tries to solve
the collected type constraints. The type var trace looks like:

    [    create] ?T                       ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [    create] ?U                       ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [    create] ?Coll                    ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [   setInst] Nothing                  ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
    [   setInst] scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=scala.collection.immutable.Nil.type )
    [   setInst] =?scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?scala.collection.immutable.Nil.type )
    [    create] ?T                       ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [   setInst] Int                      ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Int )
    [    create] ?T                       ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [    create] ?U                       ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [    create] ?Coll                    ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
    [   setInst] Nothing                  ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
    [   setInst] Int                      ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=Int )
    [   setInst] =?Int                    ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?Int )

The problematic part is when `?Int` (the type var originated from `U`) is registered
as a lower bound for `Coll`. That happens in `solveOne`:

    for (tparam2 <- tparams)
      tparam2.info.bounds.hi.dealias match {
        case TypeRef(_, `tparam`, _) =>
          log(s"$tvar addLoBound $tparam2.tpeHK.instantiateTypeParams($tparams, $tvars)")
          tvar addLoBound tparam2.tpeHK.instantiateTypeParams(tparams, tvars)
        case _ =>
      }
SI-6386 typed existential type tree's original now have tpe set

Tree reification fails for ExistentialTypeTree. The reason is that the
tree passed for reification (see reifyTree at GetTrees.scala) must have
not null tpe (see reifyBoundType at GenTrees.scala), which is not true
in the case of ExistentialTypeTree.

Why is it so? The tree passed to reifyTree was obtained in the reshape
phase of reificationusing using original TypeTrees that reporesent pre-
typer representation of a type. The problem is that original's tpe for
ExistentialTypeTree is not set.

So the solution to the issue is to create ExistentialTypeTree's original
in a such way that is has actual tpe set.
Merge pull request #2349 from scalamacros/ticket/6937

SI-6937 core type tags are no longer referentially unique
Merge pull request #2354 from adriaanm/ticket-7289

SI-7289 Less strict type application for TypeVar.
Merge pull request #2365 from u-abramchuk/SI6386

SI-6386 typed existential type tree's original now have tpe set
Merge pull request #2367 from vigdorchik/si-6387-revert

Revert "SI-6387 Clones accessor before name expansion"
SI-6286 IllegalArgumentException handling specialized method.

Specialize assigns SpecialOverride info to a specialized method
even when there is a further specialization that should be forwarded
to.
SI-7360 Don't let a follow-up TypeError obscure the original error.

When supplementing a fatal error message with context (current
compilation unit, tree, phase, etcetera), we must be cautious to
not to trigger another error which will obscure the original one.

Currently, `supplementErrorMessage` does its working a try catch
that only catches `Exception`. But this fails to catch
CyclicReferenceError (<: TypeError <: Throwable), as was seen
in a recent mailing list post by Greg Meredith.

This commit extends the catch clause.
Merge pull request #2389 from retronym/ticket/7360

SI-7360 Don't let a follow-up TypeError obscure the original error.
Merge pull request #2383 from vigdorchik/ticket/si-6286

SI-6286 IllegalArgumentException handling specialized method.
Merge remote-tracking branch 'origin/2.10.x' into merge/v2.10.1-235-g4525e92-to-master

Conflicts:
	bincompat-backward.whitelist.conf
	bincompat-forward.whitelist.conf
	src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
	src/compiler/scala/tools/nsc/typechecker/Typers.scala
	src/reflect/scala/reflect/internal/Types.scala
Merge pull request #2391 from retronym/merge/v2.10.1-235-g4525e92-to-master

Merge/v2.10.1 235 g4525e92 to master