Allow running standalone single-file scripts using Mill, Attempt #2

[lihaoyi]

Second pass at #5714, a re-run of #5820 which required more baking before merge

Initial pass, this works:

$ ./mill -f Foo.java run --text hello

[6972/6972] dist.run
watching processId file (expected content = 63396): /Users/lihaoyi/Github/mill/test/out/mill-no-daemon/pid-63396/processId
============================== run --text hello ==============================
[55/55] run
[55] SLF4J: No SLF4J providers were found.
[55] SLF4J: Defaulting to no-operation (NOP) logger implementation
[55] SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
[55] <h1>hello</h1>
[55/55] ============================== run --text hello ==============================
[6972/6972] ============================== dist.run test -i -f Foo.java run --text hello ============================== 1s

The basic approach is

• Allow -f/--file to be passed to specify a script file to use rather than build.mill
• If -f is passed, use an alternate shortened MillBuildBootstrap process that has a single build stage with a hard-coded RootModule based on the extension of the script: mill.meta.ScriptModule.Java, .Scala, or .Kotlin

In the common case where someone wants to just run a script, they can run:

./mill Foo.java --text hello

As a shorthand for the full ./mill -f Foo.java run --text hello. We special-case the first token ending with .java, .scala, or .kt to support this. I expect this would be what people want to do with their scripts the vast majority of the time, so it deserves its own extra-concise syntax even if it has some theoretical overlap with user-defined tasks ending with those names

Other notes:

• For single-file projects, we assign them a subfolder in the out folder where all the build takes place e.g. foo/bar/Baz.kt gets assigned out/foo/bar/Baz.kt/ as its out folder. Normal tasks and modules won't normally have .s in their name, so this ensures that the single-file projects won't collide with normal module and task output files

• Some of the task outputs from mill.javalib.publish have been given short-hands upickle.Readers for writing them in the YAML build header. I expect we will need to add more such shorthands in future

• Started with some basic doc sections on the per-language intro.adoc and module-config.adoc pages touching on usage of these single-file projects, but I expect we'll need more documentation

• For this PR, the single-file projects are entirely standalone and not connected to any enclosing Mill build, but that may be something we can integrate in future to allow single-file projects to define moduleDeps on the enclosing build.mill's modules

Tested with a example tests