* Add latest Mill version to MiMa checks

Pull request: #3230

Pull request: #3233

Pull request: #3239

Fixes #3241

Pull Request: #3242

…3245)

Taken from
#601 (comment)

Fixes #3100, which for some
reason is happening frequently enough on my laptop to really hamper my
productivity. With a version of Mill built from this PR, the problem
seems to have gone away.

We don't really have a strong concurrency model for what's meant to
happen when multiple Mill commands are being evaluated at once, and
trying to come up with one is a complex task that I don't think is worth
the effort. Bazel works fine with a coarse-grained lock even for huge
codebases and organizations, so this should do for Mill for now.

Pull request: #3243

Pull request: #3263

Pull request: #3264

Pull request: #3268

Pull request: #3266

Most of the functionality necessary to support Java projects is already
there, what's missing is a proper documentation and onboarding
experience. This PR aims to make a first pass at writing that and
setting up the supporting tooling necessary to do so. A Java programmer
should be able to land on `Introduction to Mill for Java`, read through
it, and competently make use of Mill for their Java project even without
significant Scala expertise.

* Since the Scala and Java modules are pretty tied together via Zinc,
for now I decided to avoid trying to split out a proper `javalib` module
and left everything in place inside `scalalib`. Instead, I defined a
`package object javalib` with a bunch of aliases pointing at the various
`scalalib` functionality; this should give us the UX benefits of letting
users `import javalib._`, without needing to invasively refactor the
codebase. There's some tradeoff with `scalalib` still appearing in stack
traces etc., but for a first pass I think that's fine.

* I added a new set of `example/basicjava/`, `javamodule`, and
`javabuilds`.
* These are duplicates of `example/basic/`, `scalamodule`, and
`scalabuilds`, but for Java. I implemented a janky DIY `build`.sc
templating/extension system, to allow me to share the bulk of the
ascidoc between the Scala/Java versions while only specifying the
differences: generally the build.sc Scala logic needs to be adapted, but
the asciidoc text and the Usage command-blocks can mostly be re-used.

* All of the Java versions of the examples have had their Scala code
ported to Java. This includes third party libraries, e.g. replacing
MainArgs with ArgParse4j, Scalatags with `escapeHtml4` from apache
commons text. Most of the `Usage` command-blocks testing the builds are
shared between the Java and Scala versions of each example, although
some had to be generalized a bit, and a handful only apply to a single
language

* The word "*Scala*" does not appear anywhere in the new documentation
pages. In general, a Java programmer should be comfortable running
through the docs, learning to use Mill, all without being scared off by
it being a "Scala" build tool

* Moved the docs for the `example/thirdparty/jimfs/` folder to the new
*Java Build Examples* section, and added a new
`example/thirdparty/commons-io/` folder to also include in those docs

With this PR, the docs have roughly the following sections:

* Scala Quick Start: Scala Specific
* Java Quick Start: Java Specific
* Mill in Depth, Mill Plugins, Reference: Language Agnostic

In future, if we include Kotlin support, we can have a `Kotlin Quick
Start` section next to that of the other two languages. It should be
pretty easy (O(days)) to duplicate all the work I did for Java for
Kotlin.

Doc changes can be reviewed locally via `./mill -i docs.localPages`

Pull Request: #3261

---------

Co-authored-by: Tobias Roeser <[email protected]>