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
minor typos in the doc of applyOrElse
SI-8266 Amend advice for deprecated octal 042

Improve the advice for `f"\042"` to read:

```
use ${'"'} or a triple-quoted literal """with embedded " or \u0022""" instead.
```

as per the discussion on SI-6476.

Knuth says that Charles XII came close to introducing octal arithmetic to Sweden,
and Wikipedia doesn't deny it.

I imagine an alternative history in which octal literals are deprecated in Scala
but required by legislation in Akka. #octal-fan-fiction
[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-8364 fixes cxTree lookup for imports

This is reminiscent of the bug that I recently fixed in paradise:
https://github.com/scalamacros/paradise/commit/0dc4e35883d357b7cbcdfd83b5b4821c1dcc0bb1.

When doing something non-standard with contexts, we usually have to keep
in mind that new contexts are created not only for trees that demarcate
blocks of code, but also for imports.
SI-8375 saner binary incompat errors for macros

Inspired by Brian McKenna's RC1 migration experience, this commit improves
macro impl binding validation in order to provide more helpful diagnostic
for this quite frequent class of errors.
SI-8368 respect user-supplied -Dscala.usejavacp in unix runner
SI-8370 fixes an infinite loop in repl init

Under a weird coincidence of circumstances provided by `sbt console-quick`,
new XML parsing logic in compiler plugin initialization could lead to stack
overflow errors.

Here's the abridged sequence events that led to this unfortunate problem
(full description can be found on the JIRA issue page):

1) Initialization of the compiler underlying the REPL would kick off
plugin initialization.

2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e.
DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml).

3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream,
requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory.

4) That request would get serviced by TranslatingClassLoader provided
by the REPL to expose dynamically compiled code.

5) TranslatingClassLoader would call translatePath that would call into
IMain.symbolOfIdent trying to map the requested resource onto one of the
classes defined by the REPL (which don't exist yet, because REPL hasn't
yet finished initializing).

6) IMain.symbolOfIdent would request IMain.global, which is exactly the
instance of the compiler that underlies the REPL, and that's currently
being initialized.

7..inf) Repeat until a StackOverflowError.
SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined

this is some weird stuff
Addresses pull request feedback