v2.2.0

Machine readable output, and the fixes needed to actually consume it

tsdec --json writes one JSON object per line on stdout: progress events
while it works, then a single result event. The human log stays on stderr
where it does not interfere. A front end should read this rather than scraping
log text, and tsdec-gui is built on
it.

tsdec --json -f log.cwl -i recording.ts -o clear.ts

Building the front end on top of it is what turned up the four bugs below.
Every one of them made the JSON unusable from a real consumer, and none of them
was visible from the command line.

Log lines ran together. tsdec_log() never terminated the line, so every
message about an analysis, a pid survey or a summary came out as one long run
of text. Invisible on a terminal, where the eye reconnects the pieces, but a
pipe received a single unparsable line, which is exactly how a front end reads
it, so a pid survey matched nothing at all.

Ctrl+C did nothing under Windows when the process was started in its own
process group, which is how a parent sends a control event to a child alone.
Windows also switches Ctrl+C off for such a child, so the signal arrived as
nothing and the run could only be ended by killing it, losing every packet
already decrypted.

Throughput and ETA were wrong on multi core runs. Both were measured with
clock(), which counts processor time rather than elapsed time. On every unix
a run on eight threads was timed as if it had taken eight times longer than it
did, understating the rate by the same factor. The Windows CRT happens to
return elapsed time, which is why this was never noticed. Both platforms now
use a real monotonic clock, and macOS uses the mach clock, because defining a
feature test macro for clock_gettime also hides _SC_NPROCESSORS_ONLN and
breaks the CPU count.

make test never ran the cancellation test. It was built and then never
executed, so the stop path had no coverage in the test target at all. It now
runs, and it generates its own recording rather than expecting one to be lying
around, large enough that the stop lands mid run on a fast machine.

Also in this release:

• tsdec_status_text(), so the command line and --json describe a return
  code with the same words instead of a front end inventing its own.
• percent on every progress event.
• total on the result event, the packet count of the input. A client needs
  it to show how far a stopped run actually got, rather than claiming it
  finished.

The stop path itself is unchanged from 2.1.0: a stop is still noticed between
blocks, the workers still drain what is in flight, and the partial output is
still packet aligned and playable.

Verified on Linux, macOS and Windows.