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.
[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)
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-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
Merge pull request #3678 from retronym/ticket/8479

SI-8479 Fix constructor default args under scaladoc
makes bundles friendly to -Ywarn-dead-code

Apparently, the `new Bundle(???).impl` synthetic tree generated as a
macro impl ref for bundles evokes -Ywarn-dead-code warnings.

This pull requests changes `???` to `null` in order not to stress out
the checker. What's in the argument doesn't actually make any difference
anyway.
SI-8537 Puts SI-8157 fix under Xsource
SI-8504 fix NPE in the Java wrapper for a Scala Map.

MapWrapper blindly calls .hashCode on keys that can very well be null.
Restrict Import-Package for scala.*

Restrict the Import-Package OSGi manifest entry to match only binary compatible scala.* packages. This is necessary, because the Scala OSGi versions do not match the OSGi semantic versioning policy and are not binary compatible between their OSGi minor versions. This means that e.g. the scala-compiler-2.11 bundle will never work if it imports a scala.* package from 2.10 or 2.12. Thus this patch enforces a tight version range, only accepting versions within the same minor version. E.g. Applied to version 2.11.1 the range would expand to "[2.11,2.12)".

Additionally, a Java 6 execution environment will be enforced for OSGi.

All module bundles need to have their own version numbers. This was not the case before this commit. Although these module bundles were only build for testing, they are needed to be correct, now, that we have stricter package import constraints and some test cases rely on them.
SI-8550 fix scaladoc for the default s.c.LinearSeq.

The default LinearSeq is a List (LinearSeq.newBuilder delegates to
immutable.LinearSeq.newBuilder, whose default is List).
SI-8549 Honour the @SerialVersionUID annotatation

In PR #1673 / 4267444, the annotation `SerialVersionId` was
changed from a `StaticAnnotation` to `ClassFileAnnotation` in
order to avoid silently ignoring non-literal UIDs like:

    @SerialVersionUID(0 - 12345L) class C

And to flag non-constant UIDs:

    @SerialVersionUID("!!!".length)

While this indeed was fold constants, the change was incomplete.
The compiler API for reading the argument from a `ClassFileAnnoation`
is different, on must look for a `LiteralAnnotArg`, rather than a
`Literal`.

This commit:

  - amends the backend accordingly
  - removes relevant duplication between `GenASM` and `GenBCode`
  - tests that the static field is generated accordingly

This will mean that we will break deserialization of objects from
Scalal 2.11.0 that use this annotation.
SI-8325 Accept infix star type outside patterns

This is a follow-up to SI-5702 which enabled use of
`*` in infix notation in patterns.

Most of the work is in distinguishing infix from a
sequence pattern.

Also, do not take backticked star as the repeated
parameter marker in postfix position. That is,
`Int``*``` is not `Int*` -- I hope double-tick
renders as tick. There is not a special use case
except that backticks mean "I am an identifier, as
is, and not a keyword."
SI-8549 Enforce serialization stability for selected collections

To date, we've been hesidant to offer any guarantees about
Java serialization of standard library types among heteregenous
Scala versions.

Nonetheless, we have added `SerialVersionUID` annotations to
parts of the standard library, to offer some stability. This
protects against two winds of change: automatic calculation of
this UID might differ between JVM versions, or it might differ
due to otherwise immaterial changes to the library in Scala
releases.

With this commit, we strengthen the guarantees. Classes
marked with `SerialVersionUID` will be serialization compatible
within minor releases of Scala. This is backed up by the
enclosed test.

After major releases, we reserve the right to break this.
But the test will serve to avoid *accidental* changes.

Specifically, the test case checks:

  - deserialize(serialize(x)) == x
  - serialize(x) is stable over time

I have included values of all types marked with `@SerialVersionUID`
in the library. For some types, I've added variations in the
values to exercise different subclasses, such as `Set1` / `Set2`.

This found that that the serialized form of predefined `ClassTags`
included the cached identity hash code and failed the stability
test. This wasn't an issue for correctness as they also provide
`readResolve`, but I marked those fields as `@transient` in any
case to comply with the test expectations.

That whole area is good example of a serialization worst-practice:
using anonymous classes in code like:

    val Object: Manifest[java.lang.Object] = new PhantomManifest[...](...) {
       private def readResolve(): Any = Manifest.AnyVal
    }

... will lead to instability if these declarations are shifted around
in the file. Named classes would be preferred. I've noted this in a
TODO comment for 2.12.
SI-6988 Test case for non-literal / non-constant SerialVersionUID

The `neg` test was already working since `SerialVersionUID`
was changed to a `ClassFileAnnotation`; the `run` test only
started working since the recently preceding commit that
made a compensatory test in the backend.