Remove unused `GlobalCompat` for compatibility with 2.8.1 and extract
the run subclassing out of the main logic of the `run` method.

The callback implementation should be independent of the compiler
interface and the source code should reflect so.

Breaking change in comparison with the previous API: `Compiler` is now
called `ZincCompiler` to make the naming more clear and better
distinguish between `CachedCompiler` and its underlying `ZincCompiler`.

Docs have been added and simplifications to methods have been provided
and double checked with previous Scala versions. For instance, `dropRun`
has been confirmed to only exist in 2.10.x series and removed in 2.11.x.
Therefore, its implementation has been moved to the compatibility traits
for 2.10.x series.  We then remove a reflective call for versions above
2.10.6.

We need `CompileAnalysis` to start creating the Java API with good docs.
Contraband is not necessary for the analysis since we only
serialize/deserialize `MAnalysis`, its subclass.

* Make `ReadStamps` a Java interface exposed in the public API.
* Create a `Stamp` interface that Java users can use without any
  knowledge of the internal requirement.
* Add docs to the pertinent Java interface.
* Change `Stamp` companion object by `Stamper` to make it Java-friendly.
  I also think the name is clearer about the contents of the object.
* Rename `internalSouce` to `source` for consistency with the Scala API.
  It's made clear that source should always be an internal source in the
  docs. This makes sense anyway, otherwise it wouldn't make sense to ask
  for the stamp of a source file that is not compiled in the current
  analysis.

`Exists` has never been used, neither internally in Zinc nor in sbt and
pants (I double checked on both).

The concept of `exists` does not make sense, since there is no value in
asserting that a stamp "exists" only in asserting that a stamp is
**not** available for a given file.

The latter is represented by the new `Stamp` API since last modified
time and hash are both optional. If both are empty, a stamp does not
exist.

`CompileAnalysis` should be an interface instead of an abstract class.

Users of `CompileAnalysis` will have access to the stamps of the files
that have been processed by Zinc.

`ReadSourceInfos` is a read-only interface for getting source info
(namely, compiler errors) associated with a given file.

This is very useful in lots of cases. Especially to process and improve
error messages in a lightweight way, though ScalaClippy already exists
for that purpose.

In any case, having access to the compiler errors outside of is of
ultimate importance for tools that want to preprocess compilation
results independently of sbt.

`OutputSetting` is like `OutputGroup` by just returns strings instead of
files. I see no reason why `OutputGroup` should not be used instead,
therefore simplifying the Zinc API and allowing users to have access to
files and not mere strings. If they want strings, they always can do
`getAbsolutePath`.

N.B. This is good for machine independence.

* Remove dangerous use of output groups as fields in compilation. In the
  case of `SingleOutput`, the source directory was invented and
  incorrect (the root). Users of the API processing this file could
  create chaos in people's computers. The new design forces consumers
  of the `Compilation` API to make up their minds and identify whether
  the compilation was used with a single output or several outputs.
  In order to do that, we return `Output` instead of an array of
  `OutputGroup`.
* Rename `outputDirectory` and `sourceDirectory` to be Java friendly.
* Augment `Output` interface with Java-friendly methods. Scala users
  can use pattern matching instead.

* Make methods in `Output` subclasses public
* Changes to the API. Java idiomatic renames:
  * sourceDirectory -> getSourceDirectory
  * outputDirectory -> getOutputDirectory

* `Compilation` has been ported to Java code and documented.
* `ReadCompilations` is a read-only API of `Compilations`.
* Add a TODO to check the ordering of the array of compilations.
* Expose `ReadCompilations` to the `CompileAnalysis`.

* Add interface for the provider.
* Rename `IvyComponentCompiler` to `ZincComponentCompiler`.
* Split `ZincComponentCompiler` and `ZincComponentManager`.
* Define `IfMissing` and `InvalidComponent` into independent files.
* Rename variables and internal API to be clearer.

No need to have it in the internal Scala side.

Previous name was incorrect, we actually return the compiled bridge.

* Remove unused code in `BridgeProviderSpecification` and test the real
  code in the default provider.
* Don't use temporary directory to download the Scala jars, retrive them
  in a directory specified by the user.
* Use `java.net.ClassLoader` instead of `ScalaClassLoader`.
* Use the `ScalaInstance` interface, not the implementation. Remove any
  reference to the implementation.

This commit makes sure that we always check that we compile against the
latest two versions in Scala 2.10, Scala 2.11 and Scala 2.12.

This commit also removes the null loggers and uses normal loggers to
check what the output of the bridge provider is. This output is
important and the rationale to do this is that it should be visible for
us in order to detect cases where there's a regression or the output is
modified in some way. Output is short anyway.

* Adds a method to fetch the default implementation of the compiler
  provider.
* Adds a method to get a default `IvyConfiguration` from a small number
  of parameters.

The public API is implemented in Java to ensure binary compatibility no
matter what happens to the internal Scala implementations. It also makes
it easier for Java users to use the API and avoid importing MODULE$'s
and Scala generated class files.'

Expose default component provider through a static method in
`ZincCompilerBridge`. This method is necessary to invoke the bridge.

Removes the previous global lock and component provider implementations
in `BridgeProviderSpecification`.

This is the proof that we're now testing the Zinc public API because
we're resolving with the ivy options and resolution specified in the
default compiler bridge provider.

It does not make sense to define it in the compiler interface since the
default implementations of class file manager and some inc options are
defined in `zincCore`.

Previously, classfile manager key was not read from
`incOptions.properties` files because there was no way to specify which
classfile manager should be chosen.

Now, the class file manager can be indeed chosen. As we cannot serialize
the logger that should be used for the transactional classfile manager
type, we reuse the one passed in at the time of reading the incremental
options values.

This is necessary for other users to implement external hooks and
reason about which files have been changed and which have not.

Java users can access it with:

```
sbt.internal.inc.Stamp$.MODULE$.equivStamp
```

* Move `JavaInterfaceUtil` to zincCore.
* Define `Changes` in `compilerInterface`.
* Define a `Lookup` interface.
  Note that this lookup interface can now be implemented by third
  parties because the stamps of the files are provided by the
  `CompileAnalysis` interface.

For God's sake, no nulls.

Previously, there was no way to get the underlying classfile manager
without depending on internal implementation details (sbt.internal.inc).

This problem is described in this issue: sbt#125.
That is a blocker for scalajs.

* Add `ClassFileManagerUtil` static methods to get access to the
  underlying class file manager implementation from both the key and the
  incremental options.
* Add docs to subclasses of `ClassFileManagerType` and the
  implementations.
* Remove closures for getting the `deleteImmediately` and
  `transactional` class file manager implementations.
* Extract implementation from anonymous classes, make them final and
  private.

In sbt 0.13.x series, there exist a transactional classfile manager that
did not have any logger on which to log its steps.

As this is not used anymore, and a classfile manager should always log
them, we remove this from the internal API.

It's safe to remove this deprecated method in M1 because it's part of
the private API (sbt.internal.inc).

This method has been deprecated and removed because class-based
dependency tracking does not need to know about internal source
dependencies anymore (in fact, this is not a useful concept for
class-based dependency tracking).

* Move `IncrementalCompilerUtil` to `ZincCompilerUtil`.
* Change `IncrementalCompilerUtil` to an interface with static methods.
* Remove bug in which ScalaInstance implementation was leaking to the
  public API.

Before, we had made this public in `sbt.inc`, but this is not necessary
anymore.

Formats for `AnalyzedClass`, `Compilation` and `Companions` were in the
public API (xsbti.api)! They have been removed from there.

Before, we were using `sbt.inc`. As we have settled to define all the
interfaces in the `xsbti.compile` namespaces, it's not worth it to force
users remember other locations for the interfaces forwarding the default
implementations in Scala.

Move the previous Scala implementation to Java as static methods.

As suggested by Eugene.