Fix incremental compilation when a Scala project depends on a Java project (#414)

* Upgrade ammonite to 1.1.2-30-53edc31

This is mainly to get https://github.com/lihaoyi/Ammonite/pull/851 which
should reduce the amount of unnecessary work done by incremental
compilation in the Mill build. This requires some code changes since
this means we now depend on a more recent version of coursier, as a
side-effect this means that we do not depend on scalaz anymore.

Also use the same ammonite version in the Mill build and in
ScalaModule#ammoniteReplClasspath.

Also remove an incorrect dependency in the caffeine integration test.
This was always wrong but did not start failing until this commit,
probably due to dependencies appearing in a different order on the
classpath.

* Rename ScalaWorker to ZincWorker

Starting with the next commit, it will be used in Java-only projects
too, so the name is misleading.

* Upgrade to Zinc 1.2.1

* Fix incremental compilation when a Scala project depends on a Java project

Before this commit, JavaModule#compile simply called javac
unconditionally, thus generating new classfiles every time. But if a
Scala project depends on a Java project, this will throw off the
incremental compilation algorithm which will unnecessarily recompile
files. To avoid this we now use Zinc to compile Java projects too (as a
bonus this means that Java compilation becomes incremental). This
required some refactoring in ZincWorkerImpl to be able to compile stuff
without having to pass Scala-specific options.

The issue solved by this commit could be reproduced by running in the
Mill repository:

$ mill main.compile
$ mill -i
@ main.compile()

and observing that before this commit, the `main.compile()` call ended
up recompiling code.

2 files changed, 4 insertions, 4 deletions

diff --git a/docs/pages/2 - Configuring Mill.md b/docs/pages/2 - Configuring Mill.md
index 7db19833..989272dd 100644
--- a/docs/pages/2 - Configuring Mill.md
+++ b/docs/pages/2 - Configuring Mill.md
@@ -72,20 +72,20 @@ def repositories = super.repositories ++ Seq(
 ```
 
 To add custom resolvers to the initial bootstrap of the build, you can create a 
-custom `ScalaWorkerModule`, and override the `scalaWorker` method in your 
+custom `ZincWorkerModule`, and override the `zincWorker` method in your 
 `ScalaModule` by pointing it to that custom object:
 
 ```scala
 import coursier.maven.MavenRepository
 
-object CustomScalaWorkerModule extends ScalaWorkerModule {
+object CustomZincWorkerModule extends ZincWorkerModule {
   def repositories() = super.repositories ++ Seq(
     MavenRepository("https://oss.sonatype.org/content/repositories/releases")
   )  
 }
 
 object YourBuild extends ScalaModule {
-  def scalaWorker = CustomScalaWorkerModule
+  def zincWorker = CustomZincWorkerModule
   // ... rest of your build definitions
 }
 ```
diff --git a/docs/pages/5 - Modules.md b/docs/pages/5 - Modules.md
index 2c13a3e9..fa6260f3 100644
--- a/docs/pages/5 - Modules.md
+++ b/docs/pages/5 - Modules.md
@@ -152,7 +152,7 @@ mill foo.Bar/qux
 
 `ExternalModule`s are useful for someone providing a library for use with Mill
 that is shared by the entire build: for example,
-`mill.scalalib.ScalaWorkerApi/scalaWorker` provides a shared Scala compilation
+`mill.scalalib.ZincWorkerApi/zincWorker` provides a shared Scala compilation
 service & cache that is shared between all `ScalaModule`s, and
 `mill.scalalib.GenIdea/idea` lets you generate IntelliJ projects without
 needing to define your own `T.command` in your `build.sc` file