SoundPatch: design a sound where it can be heard, then convert it

The bang was guessed at directly in bytes and came out as a low gurgle,
which is what guessing at bytes gets you: a cutoff of 40 looks small and
is 57 Hz, so the filter sweep ended almost shut. Voyager's sound device
is soundThing's voice engine with the editor taken off, so a patch
designed in soundThing - where there is a screen, a keyboard and a pair
of ears - makes the same sound here. What differs is only how it arrives.

SoundPatch converts one into the other. Every parameter the device takes
is a documented function of a natural value and all of them invert: times
are squared into four seconds, cutoff and rate are exponential, depths
and detune are centred on 128. It writes a table of a count and that many
parameter and value pairs, and playPatch hands it to the device - so
every sound after this costs a table and a call rather than forty lines
of its own.

Two things the conversion has to say out loud. soundThing has no field
for the level routing, because there it is always the amplitude envelope,
so the table says so explicitly - a channel keeps its patch between notes
and a leftover from a previous one would otherwise be carried in. And a
field the tool does not recognise STOPS it: a patch format that has moved
on would otherwise produce a table that quietly means something else.

THE BUILD DOES NOT DEPEND ON IT. soundThing lives in its own repository
and is not needed to build anything here; the tables are checked in and
the tool is for when a sound is being changed.

Lander's crash now plays Kick808 as a stand-in until a bang is designed
for it, and the difference is the point: the hand-guessed patch wandered
between 1600 and 8200 for eight tenths of a second, and this decays
3492, 2743, 2037, 1515, 1040, 614, 87, nothing.

The docs check caught the tool count in two manuals, which is what it is
for.

SplitBit Test Manual.md

@@ -37,7 +37,7 @@ Everything in between is somewhere on that line.
 make test
 ```
 
-Builds the four tools - and Voyager, where Raylib is installed - checks they compile under
+Builds the five tools - and Voyager, where Raylib is installed - checks they compile under
 strict ISO C, and runs the scripts in order. Takes a few seconds. Everything must pass; there are no expected failures at the
 level of the suite, only tests that record an expected failure of the assembler.
 
@@ -45,7 +45,7 @@ level of the suite, only tests that record an expected failure of the assembler.
 make sanitize
 ```
 
-The same suite with the four tools rebuilt under AddressSanitizer and
+The same suite with the five tools rebuilt under AddressSanitizer and
 UndefinedBehaviorSanitizer. See [The Sanitizer Run](#the-sanitizer-run).
 
 Individual scripts can be run on their own, from anywhere:
@@ -540,7 +540,7 @@ which stops the markers outliving the code they were about.
 make sanitize
 ```
 
-Rebuilds all four tools with `-fsanitize=address,undefined` and runs **the whole suite**
+Rebuilds all five tools with `-fsanitize=address,undefined` and runs **the whole suite**
 under them. What it reliably catches is invalid access: reads and writes off the end of an
 array, use after free, leaks, and arithmetic the standard does not define.
 
@@ -552,7 +552,7 @@ deliberate `calloc`. The machine's Program and Data memories are static arrays,
 sanitizers neither fill nor bound-check - which is the same fact, seen from a
 different side, as the overrun blind spot below.
 
-It runs everything because it used to not. It built all four tools sanitized and then ran
+It runs everything because it used to not. It built all five tools sanitized and then ran
 only `run.sh` and `terminal.sh`, so SplitDisk was compiled with the sanitizers and never
 exercised, and `native.sh` - which drives the assembler and the emulator harder than
 anything else here - was skipped entirely. Those are exactly where block arithmetic on disk