Backports library changes related to SI-6566 from a419799

The idea of backporting this occured while developing the -source flag
for SI-8126 : withouth this the library breaks at refchecks for a
Scala compiler that checks type aliases variance.

This shoudl be BC and promote good hygiene.
[nomaster] Update MiMa and use new wildcard filter

scala.reflect.internal._ now gets a free pass from binary
compatibility checking.

Previously, we had to excrutiatingly exclude violations individually.
[nomaster] SI-8146 Fix non-deterministic <:< for deeply nested types

Backported from master. This is a squashed commmit comprising:

SI-8146 Pending test, diagnosis for bug in decidability of <:<

(cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404)

SI-8146 Test cases for typechecking decidability

Taken from "On Decidability of Nominal Subtyping with Variance"
(Pierce, Kennedy), which was implemented in 152563b.

Part of the implementation (SubTypePair) will be changed in the
following commit to fix the non-deterministic errors typechecking
heavily nested types involving aliases or annotations.

(cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699)

SI-8146 Fix non-deterministic <:< for deeply nested types

In the interests of keeping subtyping decidable [1], 152563b
added some bookkeeping to `isSubType` to detect cycles.

However, this was based on a hash set containing instances of
`SubTypePair`, and that class had inconsistencies between its
`hashCode` (in terms of `Type#hashCode`) and `equals`
(in terms of `=:=`).

This inconsistency can be seen in:

    scala> trait C { def apply: (Int @unchecked) }
    defined trait C

    scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType
    intUnchecked: $r.intp.global.Type = Int @unchecked

    scala> val p1 = new SubTypePair(intUnchecked, intUnchecked)
    p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked

    scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations)
    p2: $r.intp.global.SubTypePair = Int <:<? Int

    scala> p1 == p2
    res0: Boolean = true

    scala> p1.hashCode == p2.hashCode
    res1: Boolean = false

This commit switches to using `Type#==`, by way of the standard
case class equality.

The risk here is that you could find a subtyping computation that
progresses in such a manner that we don't detect the cycle. It would
need to produce an infinite stream of representations for types that
were `=:=` but not `==`. If that happened, we'd fail to terminate,
rather than judging the relationship as `false`.

[1] http://research.microsoft.com/pubs/64041/fool2007.pdf

(cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59)

Conflicts:
	src/reflect/scala/reflect/internal/tpe/TypeComparers.scala
	src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
Merge pull request #3367 from retronym/backport/3363

[nomaster]  Fix non-deterministic <:< for deeply nested types
Merge pull request #3359 from huitseeker/issue/VarianceAdaptations

[backport] Backports library changes related to SI-6566 from a419799
[nomaster] corrects an error in reify’s documentation
Merge pull request #3415 from xeno-by/topic/reify210x

[nomaster] corrects an error in reify’s documentation
SI-8205 [nomaster] backport test pos.lineContent

Verifies previous behavior.
Merge pull request #3430 from som-snytt/issue/8205-backport

SI-8205 [nomaster] backport test pos.lineContent
[backport] SI-7902 Fix spurious kind error due to an unitialized symbol

Tracked down this error:

    <none> is invariant, but type Y2 is declared covariant
    <none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any

to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol
was not initialized.

This happends in the enclosed test for:

    // checkKindBoundsHK()
    hkArgs   = List(type M3)
    hkParams = List(type M2)

This commit forces the symbol of the higher-kinded type argument
before checking kind conformance.

A little backstory:

The `List(NoSymbol)` arises from:

    class PolyTypeCompleter... {
      // @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`),
      // otherwise, the non-skolemized (external) type parameter symbols
      override val typeParams = tparams map (_.symbol)

The variation that triggers this problem gets into the kind
conformance checks quite early on, during naming of:

    private[this] val x = ofType[InSeq]

The inferred type of which is forced during:

    def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match {
      case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) =>
        // If we don't save the annotations, they seem to wander off.
        val annotations = stat.symbol.initialize.annotations

(cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
Merge pull request #3491 from retronym/backport/7902

[backport] SI-7902 Fix spurious kind error due to an unitialized symbol
[backport] no longer warns on calls to vampire macros

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.

This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
SI-8420 don't crash on unquoting of non-liftable native type

Previously quasiquote's type-based dispatch failed to handle situation
where unquotee's type is native but non-liftable and was used to splice
with non-zero cardinality.
SI-8341 Refine handoff of undet. params from implicit search

In SI-7944 / 251c2b93, we discovered that typechecking of an implicit
candidate could leave orphaned undetermined type parameters in the
implicit search context. This resulted in naked type parameters
leaking into implicit expansions. The fix seemed easy: just copy
any symbols from `implicitSearchContext.undetparams` to the enclosing
context (other than ones in `SearchResult#subst`).

However, the test case in this ticket reveals a subtle flaw in that
fix: `implicitSerachContext.undetparams` only contains the type params
from the most recently typechecked candidate!

Why? Implicit search uses the same context to typecheck all plausibly
compatible candidates.  The typechecking itself is driven by
`typedImplicit1`.

Side note, that explains the heisenbug behaviour noted in the ticket:
Not *all* plausibly implicit candidates are typechecked. If
the current 'best' eligible candidate is more specific than the next
candidate, we can skip that altogether.Implicit search actually
exploits this for performance by ordering the candidates according to
usage statistics. This reordering, means that commenting out lines
elsewhere in the file changed the behaviour!

This commit simply stores the undet. tparams in the `SearchResult`,
where it is safe from the vaguries of typechecking other candidates.

That makes `Test1` and `Test2` with in the enclosed test case fail
uniformly, both with each other, and with an explicit call to
the view.

This is ostensibly a regression from 2.10.3. To get there,
we need an implicit search that has to infer `Nothing` in a covariant
position. In 2.10.3, we would just let the `G` out into the wild,
which did the right thing for the wrong reasons.
Merge pull request #3639 from retronym/ticket/8341

SI-8341 Refine handoff of undet. params from implicit search
SI-8341 minor fixup for comments in test
Merge pull request #3641 from adriaanm/fixup-3639

SI-8341 minor fixup for comments in test
RC3 will ship with akka-actor 2.3.0
Bump versions for 2.11.0-RC3
Bump version to 2.10.5 for nightly builds.