Move ICodeReader-specific logic out of ClassfileParser.

ClassfileParser contained some ICodeReader-specific logic
like `forceMangledName` and `getMemberSymbol` methods.

The `getMemberSymbol` method was defined in ConstantPool class
because it must access some internal state of ConstantPool. In order
to move that method to ICodeReader we had two options:

  1. Make all internal state accessible from outside of ConstantPool
     class so getMemberSymbol could be implemented outside of
     ConstantPool hierarchy
  2. Make it possible to subclass ConstantPool in ICodeReader so
     getMemberSymbol can be implemented in a subclass and can access
     internal state of ConstantPool

Given the fact that getMemberSymbol mutates ConstantPool's internal
state I decided that subclassing is a cleaner approach. It required
significant refactoring because we had to make sure that we create
an instance of proper class when initializing the `pool` variable.
I ended up introducing `ConstantPoolManager` class which is essentially
a mutable variable that can be reset multiple times.

This change makes ClassfileParser independent from the ICodeReader and
its implementation details.
Remove dependency on typer phase in ClassfileParser.

ClassfileParser depends on forcing infos during typer phase.
It's not entirely clear why this is needed (git blame doesn't
help much) but I decided to preserve the logic.

Therefore, I introduced an abstract method called
`lookupMemberAtTyperPhaseIfPossible` which preserves the original
semantics but is implemented outside of ClassfileParser so the
ClassfileParser itself doesn't need to depend on typer phase and
phase mutation utilities.

I removed `loaders` override in `test/files/presentation/doc`.
I would have to update it to implement the
`lookupMemberAtTyperPhaseIfPossible` method. However, the override
doesn't seem to be doing anything useful so I just removed it.
Deprecate Platform.BinaryRepr.

The 27c8266e introduced `Platform.BinaryRepr` abstract type that
was meant to abstract over binary representation of a classfile.

The abstraction was needed at the time because we had both jvm
backend and msil backend. The msil backend has been removed but
the abstraction was kept in place. The type has been deprecated
and set to be an alias for AbstractFile. The alias will be
removed later in 2.11 milestone cycle.

All references to `Platform.BinaryRepr` has been removed in
the compiler in favour of using AbstractFile directly.

If we ever need to abstract over multiple backends we should
do that based on real requirements of given backends.

This is a first step towards breaking the cyclic dependency
between Platform and SymbolLoaders.
Update sbt interface version to 0.12.4.

In particular, that version contains the
sbt/sbt@1b897a3a9422b698bf2c04103169a5eef1ff5b43 commit which removes
all residence compiler infrastructure and makes incremental compiler
less dependent on compiler internals.
Refactor the cake so SymbolTable does not depend on Global

This is rather large commit so I'll first explain the motivation
behind it and then go through all changes in detail explaining
the choices I made.

The motivation behind this refactoring was to make SymbolTable
unit testable. I wanted a lightweight way of initializing
SymbolTable and then writing unit tests for subtyping algorithm,
various functionality related to Symbols, etc.
All of that should be possible by precisely controlling what we
test, e.g., create types and symbols by hand and not have them
defined in source code as we normally do in partest (functional)
tests.

The other motivation was to reduce and clarify dependencies we
have in the compiler. Explicit dependencies lead to cleaner
design. Also, explicit and reduces dependencies help incremental
compilation which is a big problem for us in compiler's code
base at the moment.

One of the challenges I faced during that refactoring was
cyclic dependency between Platform and SymbolLoaders.

Platform depended on `SymbolLoaders.SymbolLoader` because it
would define a root loader. SymbolLoaders depended on Platform
for numerous reasons like deferring decision how to load a given
symbol based on some Platform-specific hooks.

I decided to break that cycle by removing methods related to
symbol loading from Platform interface. One could argue, that
better fix would be to make SymbolLoaders to not depend on Platform
(backend) concept but that would be much bigger refactoring. Also,
we have a new concept for dealing with symbol loading: Mirrors.

For those reasons both `newClassLoader` and `rootLoader`
were dropped from Platform interface.

Note that JavaPlatform still depends on Global so it can
access phases defined in Global to implement `platformPhases`
method.

Both GenICode and BCodeBodyBuilder have some Platform specific
logic that requires casting because pattern matcher doesn't narrow
types to give them a proper refinement. Check the changes for details.

Some logging utilities has been moved from Global to SymbolTable
because they are accessed by SymbolTable. Since Global inherits from
SymbolTable this should be a source compatible change.

The SymbolLoaders has dependency on `compileLate` method defined in Global.
The purpose behind `compileLate` is not clear to me but the dependency looks
a little bit dubious. At least we made that dependency explicit.

ScaladocGlobal and Global defined in interactive has been adapted in a way
that makes them compile both with quick.comp and 2.11.0-M4 so my refactorings
are not blocking the modularization effort.
The `test-junit` Eclipse project depends on `scala-compiler`

We want to write JUnit tests for Scala compiler so we should depend
on `scala-compiler` project in `test-junit`.

Also, make dependencies of `scala-compiler` project exported so it's
enough to depend on `scala-compiler` to get all the transitive
dependencies that are needed by the compiler. Otherwise, one would
need to copy all dependencies of Scala compiler to all Eclipse projects
that depend on the compiler.
Add example of SymbolTable unit test.

Add a SymbolTableTest which contains all the code needed to
initialize a SymbolTable in JUnit environment. It shows
that initialization of definitions works and one can easily
lookup some symbols and perform tests like subtyping tests.
Fix Platform type in Global to be JavaPlatform.

At the moment we have just one Platform: JavaPlatform in the
compiler. The whole Platform abstraction feels dubious and
Java backends need to downcast to JavaPlatform to implement some
optimizations. It seems like for now it's just better to fix platform
declared in Global to be JavaPlatform and get rid of downcasting.

I checked that even JavaScript backend declares itself as a subtype
of JavaPlatform so it seems like our abstraction is not that useful.

If we have an alternative platform with specific requirements we
might want to refactor our Platform abstraction again but for now
it seems dubious to pay a price for abstraction nobody uses.