Finish flat classpath implementation

Finished implementations for various classpath types - also using ManifestResources.
In accordance with the idea and the initial implementation of @gkossakowski they
try to make the best use of the specificity of a given file type instead of using
AbstractFile everywhere. From now flat classpath really works and can be turned on.

There are following types of flat classpath:

for both source and class files:
- for directories - it uses the real directory having representation on a disk
- for zip and jar files - it uses FileZipArchive - Grzegorz was doing some
experiments with different ways of handling such files (efficiency etc.) and
stated that this one is the best.

- aggregate - equivalent of MergedClassPath from the old implementation. It groups
classpath instances created for different files. It ensures the distinction of cp
entries and merges corresponding entries for class and source files into one entry
as SymbolLoaders class makes use of that.

only for class files:

- for ManifestResources - it's closely related to the support for JSR-223 and to
classes listed in the manifest file placed in the JAR. In general right now it's
not possible to use it in Scala out of the box (without using additional tools
such as jarlister) as this support is postponed. The old classpath has been properly
prepared in the PR created by @rjolly https://github.com/scala/scala/pull/2238 so the new one also got this feature.
ManifestResources is a ZipArchive without a real underlying file placed on a disk and
in addition implementing some methods declared in AbstractFile as unsupported
operations. Therefore the implementation has to use the iterator provided by AbstractFile.

There's added caching for classpath for zip and jar files and also for ManifestResources.
It can be turned off using a flag -YdisableFlatCpCaching. The cache is just a map
AbstractFile -> FlatClassPath what should reduce the number of created cp and file
instances e.g. in the case of many ScalaPresentationCompilers in Scala IDE. There's
no added cache for loaded symbols etc. (honestly I didn't look at that - I'm even not
sure how much sense would have such things).

In SymbolLoaders there's added PackageLoaderUsingFlatClassPath that was needed as
the new implementation uses relatively few cp objects which can return entries from
many packages. In the case of old implementation there's the structure of nested
classpath objects, where each such an object can return only entries from one level of
hierarchy but it returns also another classpath objects for nested levels included in it.

The sbt compiler interface hack is removed - instead of it there's introduced the dynamic
dispatch in a Global's classPath method. The type of a classPath is changed from
ClassPath[AbstractFile] to ClassFileLookup[AbstractFile] but it should be okay as
ClassFileLookup defines needed methods. I tested it with sbt and everything seemed
to work correctly. But it could be problematic if someone uses a classPath from a Global
and requires exactly the type of the old implementation. I'm not aware of such cases.
In the case of compatibility problems with some libraries using compiler's internals we
could think about bringing back some hacks. But it would be better to avoid this.

There's added PathResolverFactory which is used instead of a concrete implementation of
a PathResolver - it dispatches to the proper classpath implementation so, in combination
with matches in some other places, in all places using classpath we create/get the proper
type.

Scalap's Main.scala is changed to be able to use both implementations and also to use
flags related to the classpath implementation. By the way the structure of its methods
has been refactored - there's no change in a way scalap works.

The classpath invalidation is modified to work properly for the old cp implementation
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.

As I always do - I removed unused private methods, unused imports and commented out lines
which I saw by the way and were obvious for 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.
Add tests for flat classpath

Added:
- Tests comparing entries created using the old and the new classpath implementations.
- Tests for AggregateFlatClassPath which check whether it obtains correct entries from classpaths
specified in a constructor and whether it preserves the ordering in the case of repeated entries.
- 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 many types of entries specified as -classpath and -sourcepath.

Sample JUnit test that shows that all pieces of JUnit infrastructure work correctly now uses JUnit assert
as it should do from the beginning.
Add benchmarks to compare recursive and flat classpath implementations

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 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 a profiler like JProfiler to
look how given implementation behaves.

Also set flat classpath implementation as a default one (e.g. to test on Jenkins)