test: run the commands and tasks suites in parallel

[josegonzalez]

Closes #502. Closes #515. Closes #516. Closes #517. The process globals that kept commands/ and subprocess serial are gone, and both suites now run in parallel.

The command layer's tests were the ones held serial longest. Export's tests move off subprocess.SetExecRunner onto the run context, the formatter builds its own color objects instead of reading color.NoColor, and the three tasks/ files that #502a left behind convert with the rest.

Decoupling the formatter from color.NoColor means that flag no longer answers two unrelated questions. noColorDefault picks up the TERM=dumb case it was leaning on fatih/color for, and subprocess asks isatty directly rather than reading a colouring decision to decide whether a child may inherit stdin - which is why NO_COLOR=1 used to stop it.

With every test carrying its fake on the context, the swappable package variable behind SetExecRunner has no users left and goes too, along with the mutex that only existed to keep a test writing it from racing a test reading it. The two tests written against the setter are rewritten rather than dropped: one pinned that a fake receives the input and that a bare call reaches the real executor, and the other pinned precedence between the two seams, which is now precedence between a context and the one it derives from.

The last serial tests were the ones arranging environment variables, so parseDokkuHost and resolveSshFlags take the lookup as a parameter and production passes os.Getenv. Four of those tests were clearing DOKKU_SUDO and DOKKU_SSH_ACCEPT_NEW_HOST_KEYS against a function that has not read either since they moved onto an explicit Target, so that clearing goes rather than moves. subprocess is then swept the way tasks/ and commands/ were.

Parallelising commands/ surfaced a real bug rather than a test problem. Rendering a recipe goes through sigil, which exports each template variable into the process environment and restores it by replaying a snapshot through os.Clearenv. Two renders at once interleave a wipe with a restore, and because each replays the snapshot it took, an unlocked render emptied the entire environment - PATH and HOME included. Those writes existed only to feed sigil's POSIX preprocessor, which is gated on a flag docket has never set, so tasks.RenderTemplate is now a reimplementation of Execute that renders without touching the environment at all: the same $var scan, the same prelude, the same escaped-delimiter fixup, the same SIGIL_DELIMS override, and sigil's own builtins. include and render are docket's, because sigil's recurse into Execute. A render lock remains, for sigil's template path stack rather than the environment.

Owning the function map settles a second inconsistency. Sigil keeps one package-global map that sigil/builtin fills from an init, so a builtin existed only if something in the binary imported that package - main.go did and some test files did, but the commands test binary did not, leaving {{ .app | upper }} working in the CLI and failing to parse in those tests.

Seven tests stay serial across the three packages, each saying why in place: two are the colour-detection cases, whose subject is the environment; one counts runtime.NumGoroutine(), which is process-wide; one asserts a wall-clock ceiling; one asserts a child inherits docket's environment; one reads its trace back through the standard logger's output; and one writes color.NoColor deliberately, to show nothing reads it any more. Go resumes parallel tests only once every serial test and its cleanups have finished, so those seven keep working beside the rest.

This buys little wall-clock time - the suites are mocked and were already fast. The point is that -race now watches a concurrent program rather than a serial one.