18cc216a

Number the mutation progress lines by how many have started

The `[X/Y]` counter on a mutation run's progress lines was each mutation's
position in the manifest, which is no longer the order the mutations are tested
in: the groups run concurrently, and the most expensive of them are started
first.  A run's log therefore read like this:

```
[  23/2850] Testing mutation RemoveAction at src/NixCI/Leader/WebServer/Foundation/RepoUrl.hs:165:5-59
[  24/2850] Testing mutation RemoveAction at src/NixCI/Leader/WebServer/Foundation/RepoUrl.hs:164:5-61
[ 151/2850] Testing mutation ConstEmptyList at src/NixCI/Leader/SeatUsage.hs:83:42-61
[ 150/2850] Testing mutation ConstEmptyList at src/NixCI/Leader/SeatUsage.hs:66:3-87
[1197/2850] Testing mutation ConstNothing at src/NixCI/Leader/APIServer/Handler/GetSuiteWait.hs:93:82-86
```

Telling a reader how far along a run is is the only thing that counter is there
for, and numbers like those tell them nothing.

The number is now how many mutations have started, this one included, so it
climbs by one per line.  It is taken and written under the same lock, so the
lines reach the log in the order the numbers were handed out, and a `--debug`
run's per-mutation diffs arrive whole rather than interleaved with each other.

What this gives up is that the number no longer identifies the mutation it
belongs to.  Nothing needs it to: every line names the operator and the source
location, and the report names each mutation it has anything to say about by
id.

The counting and the writing live in `emitMutationProgress`, so the golden test
can run ten of them concurrently and show that the counter comes out as
`[ 1/10]` through `[10/10]` in order.

`nix flake check` passes.
PR #162

Total

8s

Created Started Finished

Time to Start Worker time Duration Time to finish Idle
Config 7s 1s 1s 8s 7s
Eval 12s 2s 2s 15s 6s
Build - - - - -
Suite 7s 3s 8s 15s 14s

Timeline

Config Eval Failed Retried Compressed gap
0s