Cleanups for Mill client

[lihaoyi]

• ServerFiles.* and OutFiles.* have been turned into constant fields where possible

• client/ code layout has been overhauled: MillClientMain/MillEnv have been re-organized into MillClientMain, MillLauncher, MillServerLauncher, MillNoServerLauncher

• MillClientMain.main0, now living in MillServerLauncher.runMain, has been broken down: runMillServer has been extracted out of it, and the Locks/Lock/Locked logic has been tweaked with the addition of TryLocked implements AutoClosable to let us fold some logic into the try-with-resources block

• Removed the code path for running the Mill server in-process: this cuts down the number of execution modes from 3 to 2, server and no-server. There'll be a bit of performance hit spawning another JVM for the no-server mode, but IMO it's worth it for the simplicity and maintainability of this gnarly code, and is necessary for moving the Mill os.pwd out of the root directory into a sandbox

• Some preparations for moving the Mill os.pwd out of the root directory into a sandbox, e.g. introducing a MILL_WORKSPACE_ROOT environment variable and plumbing it throughout the codebase

This should help improve the code and implementation quality of the Mill client-server codebase and set the stage for further development

[lefou]

The idea of the in-process runner was to retire the different entry points and the script-based decision logic. But it looks like you intend to keep the script logic in the prepended script. Is that so? Wouldn't it be better to optimize the Java code for in-process server and remove all the script logic?

[lefou]

Do we really need to expose this mutable variable? Can we make it final or provide a protected getter?

[lefou]

?

[lihaoyi]

opening a separate PR to finalize this and a bunch of other things that probably should be final

[lihaoyi]

final

[lihaoyi]

#3366

[lihaoyi]

I think we'll likely always have a client server architecture for performance. Keeping JVM compiler objects hot and jitted requires them to be long lived. The only question is where you draw the line:

1. Thick JVM client, thin JVM server (e.g. Bazels one-process-per-worker architecture)
2. Thin bash launcher, thin JVM client, fat JVM server (where we are now)
3. Thin JVM client, fat JVM server (possible with graal native image or scala native)
4. Thick bash client, fat JVM server (this is the only scenario where we have a single JVM running everything in process)

We are now at (2). I think trying to get to (3) makes the most sense. (1) could work, but the overhead of short lived thick JVMs is significant even if the heavy lifting compilers etc are kept alive elsewhere. (4) would probably be an unreasonable amount of complexity to implement in bash

Given the idea to move from (2) to (3) above, this PR removes the inprocess mill execution code path from the client, since we'll always have two JVMs for the reasons above