Re-support parallel evaluation of TestModule.test command

[lihaoyi]

Otherwise we cannot set def defaultCommandName to testCached, because people who run __.test will pick up both the foo.test.testUncached default command name and also the foo.test.test test command.

TBH not quite sure what the right thing to do here is

This is a binary incompatible change and will need to go into 0.13.0

[lolgab]

The biggest problem with this change is that now to pass arguments to tests you need to add a .testUncached at the end and know the difference between testCached and testUncached.
Since tests are very often not pure (flaky, etc.) I think they should not be cached by default.
If I know the whole story, the problem with the current test command is that commands are now run sequentially.
Have you thought about adding some flag to commands to make them parallel?
It could be an annotation, or a special T.parallelCommand method.

[lefou]

@lolgab
I don't think we should explicitly request parallelism via the T API. Instead, we should demarcate commands that need serial or interactive execution if we think this is required.

The run commands last and sequentially should be configurable via a CLI option or some other settings. It's already configurable in the evaluator.

[lihaoyi]

@lolgab you are right that making testCached the default causes problems passing arguments to the tests, which is very common. So that approach may be a non starter

For demarcating commands, something like T.parallelCommand seems reasonable. Some commands like clean should always run sequentially, while others like .test should be safe to run in parallel. So controlling it via a global flag doesnt really work.

Bazel has flags like exclusive = true that you can use to annotate actions

[lefou]

We closed this, without renaming test to testUncached, since with #3617 we essentially run the test command in parallel to other targets now.