Improve "building" of Mill bootstrap scripts

[lefou]

Currently, the various start files are used as-is. They are cluttered in different locations and must be edited manually, which is error-prone and cumbersome.

To properly finish up #2161 and esp. comment #2161 (comment), we should do the following:

• Move scripts (mill, mill.bat, ci/mill.ps1) into new dir scripts (or scripts/src)
• Replace all movable parts with placeholders (script version, default versions, links to web-site and download locations)
• Add a Mill build step to build final script from these templates
• Consolidate further testing under the scripts project
• Automate, when the <project-root>/mill{.bat} scripts need updates and fail CI or autofix it.

[He-Pin]

I still not get how to local build a mill and make it been used in another project locally :(

[lefou]

I used to think we had that in the readme, but it doesn't seem so.

There are basically three ways

• Using the dist.run target in the Mill repository
• Publishing locally and using the freshly build binary
• Publishing locally and editing the .mill-version file

Using the dist.run target in the Mill repository

In the Mill repo, you can run

> mill dist.run <project-dir> <other-mill-args>`

The project-dir is the project you want to build. The other-mill-args are the args you would specify to the build, e.g. the targets.

This is best, if you want to quickly test minor edits.

Publishing locally and using the freshly build binary

In the Mill repo, you run

> mill dist.installLocal

This builds a mill-assembly.jar and publishes all modules and contrib-plugins into your local ivy repository.

You can then use the mill-assembly.jar instead of the mill or local ./mill runner.

This is best, if you want to test the locally build Mill version more thorough.

Publishing locally and editing the .mill-version file

In the Mill repo, you run

> mill dist.installLocalCached

This publishes all modules and contrib-plugins as well as the mill binary itslef into your local ivy repository. It also outputs the version.

You can then edit your local .mill-version (or use MILL_VERSION env var) to contain that version and the mill bootstrap script will automatically use the locally built and published version.

It's a matter of taste, but this is the least invasive way, since all script (e.g. Makefile or justfile) and tools (e.g. IntelliJ or vscode/Metals) will work with the configured version. So this is mostly transparent to the user.