Enable use of alternative classpath impls in Global.

Previously, you could experiment with alternative classpath
implementation in JUnit only.
Get rid of classpath reference in AddInterfaces.
Disable printing classpath if flat classpath is enabled.

It doesn't work yet.
Make both {ZipFileIndex, Aggregate}FlatClasspath case classes

There are two reasons:

  * correctness: we want proper equals for ZipFileIndexFlatClasspath
    so we deal with duplicate classpath elements
  * toString implementation for nice printing
Return distinct classes in AggregateFlatClasspath

AggregateFlatClasspath would return duplicate class file entries
with the same name. This would violate other assumptions we have in the
compiler and blow up.

This should be added as contract to FlatClasspath documentation.
Implement incremental compiler classpath compatibility hack.

Incremental compiler interface depends on ClassPath.findClass method.
Since there's no common interface between the old ClassPath and
the new FlatClasspath we are stuck.

The only way I found to be compatible with incremental compiler is to
make the old classpath implementation aware of the new one, and
dynamically dispatch to FlatClasspath if it's enabled. The old classpath
is all lazy so if the only call to the old classpath is coming
from incremental compiler it'll be dispatched to the new classpath
and nothing in old classpath will get forced.
Add ZipArchiveFlatClasspath and switch to it.

More profiling has shown that ZipFileIndex is faster at reading
the entries in zip file than the standard java.util.zip.ZipFile
implementation. However, ZipFileIndex is much slower at decompressing
contents of the file. Therefore, in the end, ZipArchive wins overall.