Add a unique integer to the sandbox dir of mill --no-server

[lefou]

Fix #3395

[lihaoyi]

If we're going to create a new folder for every run, we should do a best effort to clean it up at the end in a finally block. Won't be able to catch every scenario, but at least in the happy path we won't leak folders on disk

[lefou]

Yeah, makes sense. I can add it. Should we prepare for the scenario where we want to keep the sandbox dir, e.g. for later inspection in case of a non-zero exit code?

[lihaoyi]

How about we clean up asynchronously? e.g.

1. Each process takes a lock on the sandbox,
2. Every subsequent process lists the existing sandboxes and probe the lock
3. If the lock is available, it means the process has exited, and we can delete the folder

That way for the common workflow of running Mill from the command line, we don't delete stuff immediately, but only upon the next command.

Probably something similar can be done for the long lived mill-worker-* folders as well: if the folder exists but both the clientLock and processLock are available, it means the process has exited and can be cleaned up

[lefou]

Might work. But is a bit more work than I anticipated with this quick fix. Feel free to take over this PR or merge right away and open another one for the probe-based approach.

[lihaoyi]

Let's merge it as is then

[lefou]

@lihaoyi I added basic cleanup and opened a new issue for the asynchronous cleanup idea.

• Cleanup Mill sandbox dir asynchronously #3399