Generalize OverridingPairs to SymbolPairs.

Increases your chance of knowing what is going on in
OverridingPairs. Introduces some new abstractions which I
hope for your own sakes you will put to use in some way:

  RelativeTo: operations relative to a prefix
  SymbolPair: two symbols being compared for something, and
    the enclosing class where the comparison is being performed

Fixed a minor bug with access by accident by way of more
principled pair analysis. See run/private-override.scala.

Upgraded the error message issued on certain conflicts
to give the line numbers of both conflicting methods, as
opposed to just one and you go hunting.
SI-7899 Don't infer by-name types during, e.g. eta-expansion

Given:

    def id[A](a: A): A = a
    def foo(f: (=> Int) => Int) = ()
    foo(id)

We eta-expanded `id` and inferred `A` to be `=> Int` to satisfy the
expected type set forth by the formal parameter `f`.

We really shouldn't go about inferring types that we can't *write*.
Our attempt to do so led promptly into a `ClassCastException` in the
enclosed test.

This commit:

  - drops by-name-ness during `inferExprInstance`
  - tests that this results in a type error for the reported bug
    (neg/t7899)
  - tests that a method with a by-name parameter can still be
    eta expanded to match function with a corresponding by-name
    parameter (run/t7899)
  - discovers the same latent CCE in pos/t7584
     - now that would be a type error
     - so we compensate by using placeholder functions rather than
       eta-expansion.
     - and move that that test to `run` for good measure.
Merge pull request #3022 from retronym/ticket/7899

 Don't infer by-name types during, e.g. eta-expansion
Merge pull request #3020 from paulp/pr/overriding-pairs

Generalize OverridingPairs to SymbolPairs.
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
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 enteringPhase 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`
(only in SynchronizedSymbols, not in normal Symbols) again due to those
methods 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).

And then it worked, but stopped working half a year later when
Jason and I came to revisit this old pull request. The final twist
was pre-initializing ObjectClass, because it's a dependency of AnyRefClass,
which is a critical dependency of ScalaPackageClass (again, full information
can be found in comments).
it works now, but at what cost???
eagerly initializes lazy vals and objects in runtime reflection

The code to do so is curated with the help of a generator. Because this
needs to inspect code post-typer, the code generator is run during partest
as a code-validator. We could concievably do the same with a macro, but
this approach might be a better starting point which macros continue to
stabilize.

Removes Definitions.AnyRefModule and an already deprecated alias, as
these have been throwing exceptions for more than a year since 6bb5975289.
They used to be used by AnyRef specialization.
improves OSGi test runner in Ant

 - Include pack/lib/*.jar in the uptodatecheck
   - (Hopefully that saves the next guy a few hours)
 - Switch the the XML formatter (I couldn't find output from the other one)
   and mention the output directory.
tests for fancy classloader configurations
SI-6240 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.
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.
Of those only #3 is dangerous and needs protection, which is what this
commit does.
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.
synchronizes toolboxes

We don't guarantee thread-safety of the front end, but everything else
looks good now.
synchronizes pendingVolatiles

Called from isVolatile, which is called from isStable, which is a part
of the public reflection API.
removes the assertion in missingHook

In the current synchronization scheme multiple threads can enter the
missingHook trying to materialize a package, which hasn't been created.

That's fine, because makeScalaPackage, which creates and enters package
symbols is synchronized and checks whether the creation is necessary
before commencing. Therefore even if makeScalaPackage is called multiple
times in rapid succession, the calls will be serialized and all calls
except the first one won't do anything.
runtime reflection: death from thousand threads

not anymore
thread locals instead of locks for vars in Types.scala

This is one of the changes suggested by Roland in order to reduce contention
caused by reflection GIL.

Locks optimized away here are indirectly used for such fundamental operations
as subtyping tests, so the optimization looks quite important.