Rework handling of mill-launcher in MillBuildModule

[lefou]

Currently, we use the Mill launcher jar to compile the Mill project. To do that, we add it to the unmanagedClasspath of the MillBUildModule. Technically, this is correct. But in comparison with dependencies defined via ivyDeps we loose some semantics we'd like to keep. For example, when editing the build sources files, we don't have properly attached sources, as there is no metadata to use to get the sources jar on demand.

Instead we could define the dependency under ivyDeps. There are some issues to that approach, too:

• We need to download the jar (if not present), although we already have it locally as mill-launcher
• Download can fail when offline, which is a no-go, as we always want be able to build a Mill build without internet access
• When a locally build development version is used, a published jar with the same version may not exist

To overcome all of those issues, we could intercept the ivyDeps resolution of the binary mill-launcher and return the already present jar.

[lefou]

As an alternative, we could embed the sources into the mill-launcher. This will make the jar file larger, but will always provide the correct sources files for lookup.

[lihaoyi]

We should consider removing mill-launcher from the classpath and having a smaller explicitly-defined classpath. We don't want everything that Mill uses internally to be on the classpath and accessible from user build.sc files.

Things like OS-Lib, uPickle, Requests-Scala, etc. probably need to be there, but we don't want random things like org.ow2.asm or com.kohlschutter.junixsocket or org.apache.ant to end up there for users to use unless they explicitly import it

[lefou]

I agree. Then, we probably just want to define a minimal classpath via ivyDeps.

We should try to embed these needed jars as resources in the mill-launcher, so we can create a minimal local ivy repository from it and use it for bootstrapping, so we don't need to download anything for the minimal build.sc.