v2.3.0

A stop that a caller with no console can deliver

Ctrl+C is a console control event, and a front end that has no console of its
own has nowhere to deliver one from. A GUI application on Windows is exactly
that: the windowed build has no console at all, so a stop sent that way either
does nothing or arrives as a kill, and a kill discards every packet already
decrypted.

That is not a hypothetical. It is what the packaged tsdec-gui did: every test
against the Python modules passed, and the frozen executable quietly could not
stop a decode, because only the frozen build reproduces a process with no
console to signal through.

-S <file> asks for the same clean stop by creating a file, and
tsdec_set_stop_file() does the same for a caller that links the library. A
file works the same on every platform and does not care whether anybody is
attached to a terminal, which is exactly what a signal needs.

The flag is kept in a small fixed buffer and polled alongside the in-process
one, so the two mechanisms compose: a process that gets both, as a console
application does, is stopped by whichever arrives first. Nothing that already
used Ctrl+C changes.

The cancellation test now runs both paths. It had to clear the flag between
them, because it did not, and the second run was reporting as stopping
immediately with an empty output. A test that passes for the wrong reason is
worse than no test, and this one had been passing for the wrong reason since
the flag was introduced.

Also percent on the progress event and total on the result were part of
2.2.0; this release only adds the stop file.

Verified on Linux, macOS and Windows.