[WIP] Build binaries for Mill Client using Graal VM native-image

[ajaychandran]

This PR builds binaries for Mill using Graal VM native-image and adds Java/Scala/Kotlin examples for building native images.

Execution time for mill --version, with server running, shows over 5x improvement.

$ time ./mill --version
Mill Build Tool version 0.12.3
Java version: 11.0.25, vendor: Eclipse Adoptium, runtime: ~/.sdkman/candidates/java/11.0.25-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "Linux", version: 6.8.0-49-generic, arch: amd64

real	0m0.113s
user	0m0.171s
sys	0m0.037s

$ time ./out/dist/native.dest/mill --version
Mill Build Tool version 0.12.3-14-b0feea
Java version: 11.0.25, vendor: Eclipse Adoptium, runtime: ~/.sdkman/candidates/java/11.0.25-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "Linux", version: 6.8.0-49-generic, arch: amd64

real	0m0.021s
user	0m0.005s
sys	0m0.016s

Resolves #4007.

[ajaychandran]

TBD:

• Add Github actions for building and uploading binaries for different platforms.
• Update bootstrap script to download platform specific binary.

@lihaoyi
Should the existing distribution assembly be retained?

[lihaoyi]

@ajaychandran lets retain the existing assembly for now; we'll likely want to offer both runners for a while until we have confidence in the robustness of the nee one, and even then it would be nice to have a fallback (e.g. in OS/architectures the new one doesnt support)

[lefou]

Maybe, we should just use the mill.javalib package for the new modules and avoid any new type re-exports from scalalib and kotlinlib. @lihaoyi WDYT?

[lihaoyi]

@lefou I think for now following the re-export convention is probably best, once we decide what to do in #3570 we may need to break compatibility in 0.13.0 anyway, but until then we should at least keep things consistent