SI-6807 Deprecating the Actors library.

All public classes, traits and objects marked as deprecated.
Added deprecation note on the package object.
Embedded external libraries (ThreadPool etc.) are not deprecated as they are intended for internal use only.

Review by: @phaller
[nomaster] run mima both ways, filter out failures

Using @gkossakowski's contribution to mima (in 0.1.5-SNAPSHOT),
make sure bc.run doesn't fail by filtering out all binary incompatibilities.

Each subsequent commit will comment out the filters it makes irrelevant,
until we only need to filter out permitted binary incompatibilities.

We only allow binary incompatibilities in scala.reflect.internal.
[nomaster] Revert "Fixes SI-6521, overrides Range#head to be faster"

This reverts commit a557a973608a75c7a02f251bbcf49fe6f6b6655e.

This is necessary to maintain binary compatibility with 2.10.0.

Mima says:

    matchName="scala.collection.immutable.Range.head"
    problemName=IncompatibleResultTypeProblem

The bridge method appeared because result is now Int, whereas
the super-method's result type erases to Object
[nomaster] Revert "SI-4664 Make scala.util.Random Serializable"

Also revert "SI-4664 [Make scala.util.Random Serializable] Add test case"

This reverts commit 0b92073a38f9d1823f051ac18173078bfcfafc8a.
This reverts commit 2aa66bec86fd464712b0d15251cc400ff9d52821.

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] duplicate tailImpl as a private method

Reworks d526f8bd74.
This is necessary to maintain binary compatibility with 2.10.0.

    matchName="scala.collection.mutable.MutableList.tailImpl"
    problemName=MissingMethodProblem
[nomaster] bring back SerializeStart from fa3b8040eb

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] can't add new class BatchingExecutor

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] refactor AdaptedForkJoinTask, uncaughtExceptionHandler

Inlined AdaptedForkJoinTask, made uncaughtExceptionHandler private[this].

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] Revert "cosmetic renamings in runtime reflection"

This reverts commit 0429f0fd9224499cd8b606490d04b1a8dcffbca8.

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] inline importPrivateWithinFromJavaFlags into SymbolTable

This reworks 02ed5fb so that we don't change JavaUniverse's super classes.

This is necessary to maintain binary compatibility with 2.10.0.
[nomaster] Revert "SI-6548 reflection now correctly enters jinners"

This reverts commit 54a84a36d5b435a787d93ca48d45399136c7e162.

This is necessary to maintain binary compatibility with 2.10.0.

run/t6989.check had to be updated as it also (indirectly) tested SI-6548

Conflicts:
	test/files/lib/javac-artifacts.jar.desired.sha1
	test/files/run/t6548.check
	test/files/run/t6548/Test_2.scala
moves Symbol#SymbolKind to Symbols

Too bad I didn't notice that before. That will free up quite a bit of
memory, removing an extraneous field in every single Symbol, namely the:

private volatile Symbols.Symbol.SymbolKind$ SymbolKind$module
removes the crazy extraneous log
synchronizes symbols

Synchronization via decoration would be neat if it actually worked.
Unfortunately, root symbols never got decorated, therefore their children
also never got decorated and all the way down to the very turtles.

This commit fixes this sad issue by turning root symbols from objects
to lazy vals. Yes, this is going to induce a performance penalty, which
will hopefully not be high enough to invalidate this cornerstone of our
synchronization strategy.

Now when root symbols are lazy vals, they can be overridden in the runtime
reflexive universe and decorated with SynchronizedSymbol, which makes their
children sync and sound.
reflection no longer uses atPhase and friends

Mentioned methods mutate the global `atPhaseStack` variable, which can
easily lead to imbalances and, ultimately, to the empty stack error.

Luckily for us, there's only one dummy phase, SomePhase, which is used
by runtime reflection, so there is absolutely zero need to invoke atPhase
in non-compiler reflexive universes.

The cleanest solution would be to override `atPhase` for runtime reflection,
but it's @inline final, so I didn't want to pay performance penalties for
something that's used three times in runtime reflection (during unpickling, in
reflection-specific completers and in `Symbol.typeParams/unsafeTypeParams`).

Therefore I added overrideable analogues of `atPhase` and `atPhaseNotLaterThan`
which are called from the aforementioned code shared between the compiler and
runtime reflection. I also had to duplicate the code of `Symbol.XXXtypeParams`,
again due to them being very performance-sensitive.
cleans up initialization of runtime reflection

At first I just tried to remove syntheticCoreClasses from missingHook
and put them into the initializer of freshly created mirrors in order to
reduce the non-determinism in mutations of the global symbol table.

And then it didn't work, crashing on me claiming that AnyRef is missing.
Apparently we still need AnyRefClass in missingHook, just because it's
impossible to initialize (i.e. unpickle) ScalaPackageClass without it.

And then it still didn't work, whining about multiple overloaded defs
of some synthetic symbols. That was really tricky, but I figured it out
as well by initializing ScalaPackageClass first before forcing any
synthetic symbols (see the details in comments).
introduces GIL to Scala reflection

On a serious note, I feel really uncomfortable about having to juggle
this slew of locks. Despite that I can't immediately find a deadlock,
I'm 100% sure there is one hiding in the shadows. Hence, I'm abandoning
all runtime reflection locks in favor of a single per-universe one.
initializes lazy vals and inner objects in advance

As discussed at http://groups.google.com/group/scala-internals/browse_thread/thread/97840ba4fd37b52e,
`synchronized(this)` employed by lazy val and inner object initialization
is an excellent way to deadlock yourself in the foot.

Imagine a thread, which grabs a reflection GIL and then calls one of those
lazy vals / objects that reflection exposes (e.g. a companion module of
an innocently looking SingleType case class). Then imagine another thread,
which calls something else in SymbolTable, grabbing symbol table's monitor,
and then tries to get a reflection GIL to do something non-trivial. Hello,
we've just arrived at a deadlock.

Since, as discussed in the aforementioned thread, there's no easy way to
change lazy vals / inner objects in reflection to use GIL instead of
synchronizing on this, I bit the bullet and manually initialized all
things with deferred initialization defined in reflect.runtime.SymbolTable.

The list of all things `$lzycompute` has been mined by a simple Python script,
then I copy/pasted that list into `JavaUniverse.scala` and went ahead forcing
objects and lazy vals mentioned there. Notably, I've been able to force all
lazy vals in Definitions.scala.

There are some todos left, but I suggest we move forward without securing them,
because the 2.10.1-RC1 release date is very close, so we'd better have a 95%
solution instead of keeping reflection thread-unsafe. Though here's the list of
todo lazy vals for the reference:

  * BaseTypeSeq.maxDepth
  * WeakTypeTag.tpe
  * AnnotationInfo.forcedInfo

For each of those lazy vals we need to make sure that their initializers never
call back into themselves. Otherwise, there's a danger of a deadlock.
optimizes Scala reflection GIL

First of all, GIL should only apply to runtime reflection, because noone
is going to run toolboxes in multiple threads: a) that's impossible, b/c
the compiler isn't thread safe, b) ToolBox api prevents that.

Secondly, the only things in symbols which require synchronization are:
1) info/validTo (completers aren't thread-safe),
2) rawInfo and its dependencies (it shares a mutable field with info)
3) non-trivial caches like in typeAsMemberOfLock

If you think about it, other things like sourceModule or associatedFile
don't need synchronization, because they are either set up when a symbol
is created or cloned or when it's completed. The former is obviously safe,
while the latter is safe as well, because before acquiring init-dependent
state of symbols, the compiler calls `initialize`, which is synchronized.

We can say that symbols can be in four possible states: 1) being created,
2) created, but not yet initialized, 3) initializing, 4) initialized.
in runtime reflection can undergo is init. #3 is dangerous and needs protection
SI-7045 reflection now auto-initializes selfType

selfType joins the happy family of flags, annotations and privateWithin,
which automatically trigger initialization, when used within runtime
reflection.