Integrate flat classpath with the compiler

This commit integrates with the compiler the whole flat classpath
representation build next to the recursive one as an alternative.

From now flat classpath really works and can be turned on. There's
added flag -YclasspathImpl with two options: recursive (the default
one) and flat.

It was needed to make the dynamic dispatch to the particular
classpath representation according to the chosen type of a classpath
representation.

There's added PathResolverFactory which is used instead of a concrete
implementation of a path resolver. It turned out that only a small
subset of path resolvers methods is used outside this class in Scala
sources. Therefore, PathResolverFactory returns an instance of a base
interface PathResolverResult providing only these used methods.

PathResolverFactory in combination with matches in some other places
ensures that in all places using classpath we create/get the proper
representation.

Also the classPath method in Global is modified to use the dynamic
dispatch. This is very important change as a return type changed to
the base ClassFileLookup providing subset of old ClassPath public
methods. It can be problematic if someone was using in his project
the explicit ClassPath type or public methods which are not provided
via ClassFileLookup. I tested flat classpath with sbt and Scala IDE
and there were no problems. Also was looking at sources of some other
projects like e.g. Scala plugin for IntelliJ and there shouldn't be
problems, I think, but it would be better to check these changes
using the community build.

Scalap's Main.scala is changed to be able to use both implementations
and also to use flags related to the classpath implementation.

The classpath invalidation is modified to work properly with the old
(recursive) classpath representation after changes made in a Global.
In the case of the attempt to use the invalidation for the flat cp it
just throws exception with a message that the flat one currently
doesn't support the invalidation. And also that's why the partest's
test for the invalidation has been changed to use (always) the old
implementation. There's added an adequate comment with TODO to this
file.

There's added partest test generating various dependencies
(directories, zips and jars with sources and class files) and testing
whether the compilation and further running an application works
correctly, when there are these various types of entries specified as
-classpath and -sourcepath. It should be a good approximation of real
use cases.
Create possibility to skip flat classpath caching

There's added -YdisableFlatCpCaching option to ScalaSettings which
allows user to disable caching of flat representation of classpath
elements.
Cleanup and refactoring - semicolons, unused or commented out code

This commit contains some minor changes made by the way when
implementing flat classpath.

Sample JUnit test that shows that all pieces of JUnit infrastructure
work correctly now uses assert method form JUnit as it should do from
the beginning.

I removed commented out lines which were obvious to me. In the case
of less obvious commented out lines I added TODOs as someone should
look at such places some day and clean them up.

I removed also some unnecessary semicolons and unused imports.

Many string concatenations using + have been changed to string
interpolation.

There's removed unused, private walkIterator method from ZipArchive.
It seems that it was unused since this commit:
https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f
However, I had to add an exception for the compatibility checker
because it was complaining about this change.

I made some trivial corrections/optimisations like use 'findClassFile'
method instead of 'findClass' in combination with 'binary' to find
the class file.
Add benchmarks to compare recursive and flat cp representations

The goal of these changes is to add possibility to:
- compare an efficiency and a content of both cp implementations
(ClassPathImplComparator)
- examine the memory consumption by creating a lot of globals using
a specified classpath (ClassPathMemoryConsumptionTester) - it can be
considered as e.g. some approximation of ScalaPresentationCompilers
in Scala IDE when working with many projects

ClassPathMemoryConsumptionTester is placed in main (I mean not test)
sources so thanks to that it has properly, out of the box configured
boot classpath etc. and it's easy to use it, e.g.:

scala scala.tools.nsc.ClassPathMemoryConsumptionTester
-YclasspathImpl:<implementation_to_test> -cp <some_cp>
-sourcepath <some_sp> -requiredInstances 50 SomeFileToCompile.scala

At the end it waits for the "exit" command so there can be used some
profiler like JProfiler to look how the given implementation behaves.

Also flat classpath implementation is set as a default one to test it
on Jenkins. This particular change must be reverted when all tests
will pass because for now it's not desirable to make it permanently
the default representation.
Turn off flat classpath by default, mark one of its classes as sealed

This commit addresses code review comments.

The flat classpath is no longer the default classpath representation.
It was the default one just for the test purposes. For now it's not
desirable to make it permanently the default representation.

ZipAndJarFileLookupFactory is marked as sealed - it should help to
limit the ways of creating flat classpath instances for zips and jars.