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
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.
synchronizes names

Previously we didn't have all possible name creation facilities covered
with locks, so some of them silently misbehaved and caused much grief:
http://groups.google.com/group/scala-internals/browse_thread/thread/ec1d3e2c4bcb000a.

This patch gets all the name factories under control. Unfortunately it
comes at a performance cost, which has to be evaluated.
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.
replaces locks over numbers with AtomicIntegers

This is another optimization we discussed with Roland.
need to synchronize Symbols.recursionTable

Fixes this glaring omission of synchronization for a core part of Symbol.info.
makes all locks and tlses private and lazy

We do need lazy to be robust, because initialization sequence might
trigger synced operations in unexpected order, leading to NPE's.

Even if this is optimizable by removing some of the lazies or by
carefully reordering cake layers, there's no guarantee that all this
effort won't break after another reflection refactoring.