Parallelize the subprocess test suite

[josegonzalez]

Description of feature

#502 parallelised tasks/ and commands/ and #515 removed the environment coupling behind the last serial tests in both. subprocess was never swept: 26 of its 87 tests call t.Parallel(), and they got there one at a time as #504, #511 and #515 happened to touch them.

The other ~55 are not blocked by anything. mask_test.go alone holds 26 tests of a Masker each builds for itself, and controlPath, SSHError, classifySshResult and sshTarget.UserHost are pure functions over their arguments. There is no shared fixture, no package-level variable any test writes, and since #502 no swappable runner - a test that wants a fake puts it on its own context.

Five tests should stay serial, and for reasons worth writing down rather than rediscovering:

• TestCallExecCommandDoesNotLeakGoroutines counts runtime.NumGoroutine() before and after 100 calls. The counter is process-wide, so any test running beside it makes the delta measure the wrong thing.
• TestCallExecCommandDeadlineBoundsTheChild asserts a wall-clock ceiling. The margin is generous, but a timing assertion under a loaded parallel run is how a suite acquires a flake.
• TestCallExecCommandInheritsProcessEnv and TestCallExecCommandTraceLogIsMasked are the two Take the SSH defaults off direct environment reads #515 documented: the process environment is the subject of one, and the other reads its trace back through log.SetOutput.
• TestStdoutIsTerminalIgnoresTheColorGlobal writes color.NoColor deliberately, which is the only way to show that nothing reads it any more.

Go resumes parallel tests only once every serial test and its cleanups have finished, so those five keep working untouched beside the rest.

This buys no wall-clock time - the package is mocked and runs in about two seconds either way. The point is the same as #502a's: -race then watches a concurrent program rather than a serial one.