Members of value classes are moved over to the companion object early.
This change ensures that closure classes nested in value classes
appear that way to Java reflection.

This commit also changes the EnclosingMethod attribute for classes
(and anonymous functions) nested in anonymous function bodies. Before,
the enclosing method was in some cases the function's apply method.
Not always though:
  () => { class C ... val a = { class D ...} }
The class C used to be nested in the function's apply method, but not
D, because the value definition for a was lifted out of the apply.

After this commit, we uniformly set the enclosing method of classes
nested in function bodies to `null`. This is consistent with the
source-level view of the code.

Note that under delambdafy:method, closures never appear as enclosing
classes (this didn't change in this commit).

Run a number of Java reflection operations on all classes in
scala library / reflect / compiler.

The test is based on a draft by Jason.

The test is corrected (inverted) and the extractor is made
more succinct.  Succinctness isn't enforced by the test,
but I checked it manually.

Now both of the overloaded variants have a parameter list.
This seems to make type inference happier. Or it makes someone
happier.

The user is unaware whether `subsets()` takes a default arg.
But happily, empty application still kicks in.

Updated documentation of + and ++ in SetLike to explicitly state that duplicate elements
are not added to the set.

Improve attribute parsing and propagate errors
across event thread. Otherwise tests just hang.
This is tested, right?

This is an upstream port of scala-xml
5f2cfadeb9e8574ed66f37dc7a7a868eb129a8a9

SI-8759 bump jline: support alt-gr-based keyboards

SI-8841 report named arg / assignment ambiguity also in silent mode.

Use `j.l.Class.isInstance` for Scala.js, so that `unapply`
works correctly when referencing raw JavaScript classes.

Inline overloaded calls to `unapply`, so we can get rid of them in 2.13.

Note that theres a lot of `box(unbox(x))` going on behind the scenes.
Is this needed?

As it turns out, we generate properties files only for those three
subprojects.

We mimic what Ant build does.

Before this commit, we used to have common way of handling names of
subproject. We would construct the name by prepending "scala-" suffix to
project id (which is simply the name of directory in src/). It turns out,
our projects are not named uniformly. For example, we have just "repl" and
not "scala-repl".

In this commit, we give up on central naming logic and have manual settings
for each subproject that requires special handling.

Let's override `sources` task to return empty collections of sources to
compile. Otherwise, sbt by default would pick up sources in the root
directory which is not what we want.

Actors get properties files generated so we need to add settings for that.
Also, the jar is called "scala-actors.jar" so we need to tweak the name
of the project.

Shell scripts are generated with `mkBin` sbt task that calls ScalaTool.
ScalaTool is defined in project/ and is a port of Ant task that lives
in scala.tools.ant.ScalaTool. While porting, we've simplified the code
significantly.

The `mkBin` task is defined in a new subproject: dist. This subproject
will become responsible for building the distribution in the future.

This way we don't need to worry about mixing classes for Scala compiler
that sbt is invoking and the one we just built. For an example of
possible problem, check out:

#2 (comment)

Those jars are put by Ant build in build/pack/lib but they are not needed
to be there.

Common library dependencies are extracted into vals.
Those dependencies define "scala-library" as an excluded transitive
dependency so we don't get eviction warnings during `update`.
Lastly, version numbers for dependencies are obtained from
`versions.properties` file.

 - Explicitly set [un]managed[re]sourceDirectories for all
   projects to improve the import into IntelliJ
 - Add partest extras project, that contains scala/scala specific
   extensions to partest for use in partest and junit tests.
 - Add junit project, which contains unit tests for the compiler and
   library.

All partests pass. Partest tests are defined in Integration configuration.
This means you need to run them with `test/it:test` command. We put them
in separate configuration because they are slow to run so user needs to
ask explicitly for partest to run.

Introduce a common way of setting jar location so it can be reused between
`scalaSubprojectSettings` and `partestJavaAgent`. This reduces code
duplication.

The 6e6632e introduced a junit test
for scaladoc. We need to take that into account in sbt build.

Add welcome message that is shown at sbt's startup. The message clearly
indicates experimental status of sbt build.

Also, add a short paragraph to README.md explaining status of sbt build.