SI-5905 Sanity check -language options

The option names are hardcoded, but checked by a test.

There are no hooks to verify options after the compiler
is constructed.

Introduced a `MultiChoiceSetting` required for the
setting creation framework.
SI-5905 Restore -language:_

Underscore means all.

-x:c,b,a,_ results in value c,b,a,a,b,c,d,...

Currently, -Xprint does not present phases as a closed
set of choices; there is ad hoc checking in Global.
That would be a nice unification. (You don't know the
list of choices until after global is constructed.)
SI-8196 Runtime reflection robustness for STATIC impl details

Scala's runtime reflection works in few modes. The primary mode reads
reads out the pickled signatures from ScalaSig annotations, if
avaialable. However, these aren't available for Java-defined classes
(obviously) nor for local Scala-defined classes (less obviously.),
and the Scala `Symbol`s and `Types` must be reconstructed from
the Java generic reflection metadata.

This bug occurs in the last case, and is centered in
`FromJavaClassCompleter`.

In that completer, member fields and methods are given an owner
based on the STATIC modifier. That makes sense for Java defined
classes. I'm not 100% if it makes sense for Scala defined classes;
maybe we should just skip them entirely?

This patch still includes them, but makes the ownership-assignment
more robust in the face of STATIC members emitted by the Scala
compiler backend, such as the cache fields for structural calls.
(It's reflection all the way down!). We might not have a companion
module at all, so before we ended up owning those by `NoSymbol`,
and before too long hit the dreaded NSDHNAO crash.

That crash doesn't exist any more on 2.11 (it is demoted to a
-Xdev warning), but this patch still makes sense on that branch.

This commit makes `followStatic` and `enter` more robust when
finding a suitable owner for static members. I've also factored
out the duplicated logic between the two.
SI-8195 Test case to show this is a dup of SI-8196

Which was fixed in the previous commit.
SI-8144 permalinks in scaladoc
SI-8415 Exception handling in REPL init

Incremental robustness, and probe for typer phase.

The probe would be unnecessary if repl contributed a
terminal phase that "requires" whatever it needs; that
is checked when the Run is built.
SI-7992 Fix super-accessor generation after a local class

The transformer in the superaccessors phase uses the var
`validCurrentOwner` to track whether we're in a part of the
code that won't end up in the host method, and as such, will
need to access super-method via a super-accessor.

But, this bit of bookkeeping was not correctly reset after traversing
out of a local class. A `VerifyError` ensued.

This commit changes `atOwner` to save and restore that flag, rather
than leaving it set to `true`.

I've also added a test variation using a by-name argument.
SI-8329 Better hygiene for patmat partial functions

Don't enter synthetic parameters of `applyOrElse` et al into
scope when typechecking the user-code; instead reference those
symbolically.

There is an exception to this principle. Currently we allow:

    val x: PartialFunction[A, B] = x => x match { ... }

For this pattern of code, we use the given name `x` for the
corresponding method parameter of `applyOrElse` and `isDefinedAt`
and we actually need this to be in scope when we typecheck the
scrutinee. This construct is tested in `run/virtpatmat_partial.scala`.

A new parameter, `paramSynthetic`, differentiates this
case from the more typical `val x: PF[A, B] = { case ... => ... ; ... }
case, which uses a fresh name need not be in scope. (We could get
away with it, as it is fresh, but I thought it better to exclude it.)
[nomaster] typecheck(q"class C") no longer crashes

MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.

This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.

(cherry picked from commit 609047ba372ceaf06916d3361954bc949a6906ee)
SI-8430 Less non-determinism in patmat exhautiveness warnings

Another mole whacked on the head by using `LinkedHashMap`.

Caution: `LinkedHashMap` doesn't preserve its runtime type if
you map through the generic interface. I've noted this gotcha as
SI-8434. I've structured this patch to enforce that concrete
collection with types, which is a good idea anyway.

My method to track this down was to place breakpoints in
`Hash{Map,Set}`.{foreach,iterator}` to see where that was
used from within pattern match translation. This approach was
drastically faster than my previous rounds of whack-a-mole.

The counter-examples are still a bit off; I'm going to merge
that aspect of this ticket with SI-7746, in which we've
pinpointed the culpable part of the implementation, but haven't
had success in fixing the bug.
Merge pull request #3614 from retronym/ticket/8196

SI-8196 Runtime reflection robustness for STATIC impl details
Merge pull request #3551 from xeno-by/topic/typecheck-member-def

[nomaster] backports 609047ba37
SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`

And update the java `ClassFileParser` to create distinguished
`StubClassSymbol`s, rather that a regular `ClassSymbol`s, when
encountering a deficient classpath. This brings it into line
with `Unpickler`, which has done as much since a55788e275f.

This stops the enclosed test case from crashing when determining
if the absent symbol, `A_1`, is a subclass of `@deprecated`.

This is ostensibly fixes a regression, although it only worked in
`2.10.[0-3]` by a fluke: the class file parser's promiscious
exception handling caught and recovered from the NPE introduced
in SI-7439!

	% javac -d /tmp test/files/run/t8442/{A,B}_1.java &&  qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala
	warning: Class A_1 not found - continuing with a stub.
	warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class
	two warnings found
Merge pull request #3655 from retronym/ticket/8442

SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`
SI-8450 no "implicit numeric widening" in silent mode

Before this fix, we get a second, spurious warning.

```
t8450.scala:5: warning: implicit numeric widening
  def elapsed: Foo = (System.nanoTime - 100L).foo
                                      ^
t8450.scala:11: warning: implicit numeric widening
  def elapsed: Foo = (System.nanoTime - 100L).foo
                                      ^
error: No warnings can be incurred under -Xfatal-warnings.
two warnings found
one error found
```

By respecting silent contexts, we now get only one.

I sneakily fixed similar occurrences without adding a test.
 SI-8463 Avoid unpositioned errors from search for views

Ideally, I'd like to fix this using `saveErrors = false` here to
firewall the enclosing context from the ambiguiouty error encountered
during implicit search.

I originally proposed that patch as a fix for SI-8419 in
https://github.com/scala/scala/pull/3460 but withdrew from
that approach as I uncovered a deeper bug that meant that
we actually shouldn't have even been looking for views in
that case.

But, this runs into SI-8230 and these failures:

	test/partest --update-check \
	  /Users/jason/code/scala/test/files/pos/t2504.scala \
	  /Users/jason/code/scala/test/files/pos/t4457_1.scala \
	  /Users/jason/code/scala/test/files/neg/t4457_2.scala

Turns out that typechecking the ostensible straight forward
application, `Array("abc")`, hinges on us leaking an ambiguity
error from `viewExists` to find a path through overload resolution!

This commit takes a tiny step forward by using `context.tree`
rather than `EmptyTree` as the argument to `inferImplicit`.
This avoids unpositioned type errors.
Update references to quasiquotes guide
SI-8461 -Xsource:2.10 mode for macro signature checks

I can't get the test to fail in partest, so I've resorted to
a manual test case.

    % qbin/scalac -nobootcp -Dscala.usejavacp=false -Xsource:2.10 -classpath $HOME/.m2/repository/org/scala-lang/scala-library/2.10.3/scala-library-2.10.3.jar:$HOME/.m2/repository/org/scala-lang/scala-reflect/2.10.3/scala-reflect-2.10.3.jar test/files/pos/t8461/Impl.scala
    warning: there were 1 deprecation warning(s); re-run with -deprecation for details
    one warning found

    % qbin/scalac -nobootcp -Dscala.usejavacp=false -Xsource:2.11 -classpath $HOME/.m2/repository/org/scala-lang/scala-library/2.10.3/scala-library-2.10.3.jar:$HOME/.m2/repository/org/scala-lang/scala-reflect/2.10.3/scala-reflect-2.10.3.jar test/files/pos/t8461/Impl.scala
    test/files/pos/t8461/Impl.scala:6: error: macro implementations cannot have implicit parameters other than WeakTypeTag evidences
      def reads[A] = macro readsImpl[A]
                           ^
    one error found

Before this change, when using a 2.10 JAR for scala-reflect, the
macro signature validation checks failed. This was due to the fact
that `scala.reflect.macros.Context` was changed in 2.11 to be
a type alias.

To get things working again, I've had to route both
`defintions.{WhiteBoxContextClass, BlackBoxContextClass}` to the
old location. This might mean that we misclassify the boxity under
this mode. All that we can actually handle are blackbox macros, really,
as macro expansion is likely to hit binary incompatibilites very
quickly. We can refine this in subsequent releases.
Render scala.full.version to versions.properties.

When called with -Dupdate.versions, the build will render its current
set of versions to versions properties. This is used during releases,
when bootstrapping to a consistent set of modules that constitute
a release.

Particularly, scala.full.version is the non-SNAPSHOT full version
of scala that's closed to maven.version.number. It's similar in
spirit to the module build's snapshotScalaBinaryVersion,
except that it's always the full version, so, e.g., 2.11.1 rather than 2.11.

This version is so far only used to determine the dependency on
scala-continuations-plugin in scala-dist.
SI-8479 Fix constructor default args under scaladoc

The `DocDef` node hid the `DefDef` constructor from the scrutinee
of the namer when determining if the class had constructor defaults
or not.

The current pattern for fixing these bugs is to delegate the check
to `TreeInfo`, and account for the wrapper `DocDef` node. I've
followed that pattern, but expressed my feelings about this approach
in a TODO comment.

Before this patch, the enclosed test failed with:

     error: not enough arguments for constructor SparkContext: (master: String, appName: String)SparkContext