Upgrade to Bullseye

See merge request !6

Mention its now built with Bullseye, and also provide a link to the old
page in case you need Buster for some reason. Will have to keep that
link updated (tempted to change the old release to default to 90s
style).

Update RAM requirement, too. Probably the apt index workaround causing
the higher RAM requirement. (Does anyone have 768MB or less anymore?)

Debian bug 994982 causes live-build to fail with an "Unable to locate
package squashfs-tools" error. It's fixed in bookworm, but that isn't
released yet. So put the indices on the iso for now. Makes the image
slightly larger.

First up, just s/buster/bullseye/g. See how much work we have to do to
get this building and working with Bullseye. Not anticipating much, but
you never know.

Second, update LEGAL file with SPDX data. Appears it's now required,
causing the build to fail. There isn't an exception that matches our
OpenSSL exception (but it close to openvpn-openssl-exception — that may
be where I got the language from). Update the copyright year, too.

Third, add perl-xs-dev. Appears to be needed to build now.

Fix spelling of "received"

See merge request !4

New modern style, thanks Ruben Albornoz.

See merge request !5

Looks like GitLab tightened some security settings, now live-build
doesn't work on their runners. So bring my own... Annoying.

It's taken me forever to merge it, but thank you
Ruben Albornoz @ https://cont3mpo.github.io for this modern CSS stying
for ABAN.

The old one is available as an alternate style sheet,
labeled "Very 90s" ☺

Update README.headless

Fixed a typo.

See merge request !3

Closes #23.

Now handle if it dies during wipe or verify. We also no longer consider
it done when it sends the verify done message, we now wait for it to
actually exit. It could still die (in theory, closing the filehandle
could die), and setting something done twice is silly. So instead its
back to pending, which is typically immediately followed by done.

Previously, the code just knew that when a wipe starts, that's one fewer
pending. Or that when a wipe finishes, that's one less wiping. Etc.
This, though, gets harder when errors are handled, as you start adding a
lot of cases. So now, track the current state, so we can decrement that
count regardless of what the new state is.

This is the easy part; no state to worry about here, we haven't started
yet.

Closes #4.

All four of them were very similar, a quick higher-order function gets
rid of that duplication.

Have ABAN call wipe-disk in --wipe --verify mode, and parse the
resulting output. Closes #4.

TODO: The _complete and _start subs in ABAN.pm are rather repititive;
going to refactor them.

Verify mode has a little too much copy & paste from wipe mode (in the
setup, which is almost identical). Don't particularly like the global
$TODO either, but for now neither of these seem worth the effort to fix.

Had to change the START and COMPLETE messages since that'd no longer be
unique. Now have WIPE_START, WIPE_COMPLETE, VERIFY_START,
VERIFY_COMPLETE.

This is most of the way to #4, but not yet as ABAN doesn't yet use
verify mode.

If we'd made no progress by the first etr call, would divide by 0. This
can happen if every block we've tried has failed.

The verify mode needs the same logic to iterate over blocks (e.g., it
needs the same small-large-small pattern for alignment). The difference
is just in the innermost loop, where instead of generate-write it needs
read-generate-compare.

Verify mode isn't implemented yet, but the options handling is now saner
and its fully documented. With actual manpage-style pod (which the build
should convert to a manpage).

Built some Docker images with a bunch of stuff pre-installed, this
speeds up the CI builds a lot. Build-32 and -64 go from around 6m to
around 3m.

This doesn't help the iso-* jobs, so leave them alone.

Will now confirm if there is a keyboard present to respond on.

If we detect a keyboard (something that claims you can press Y/N), then
prompt for confirmation before wiping. Otherwise, proceed without
confirmation.

Closes #18.

Finally, something obvious progress towards #18. Use the input
capabilities modules I just wrote to detect if there is a keyboard,
defined as anything you can press Y and N on.

Of course, it could be a barcode reader, but then I guess you can scan
Y. Or it could be a Yubikey, in which case... I guess plug in a USB
keyboard?

One surprise, it turns out Bit::Vector->contains errors out if we ask
about a bit larger than the vector, instead of just returning 0. So
protect against that. (And of course it only happened on 32-bit, since
the size is always a multiple of the word size, so larger on 64-bit).

This is just much simpler going forward, and a lot less "magic"
happening. Just put the autogenerated code in its own module, instead of
the main one via trickery.

Add author and t-data to the code organization section.

This is mostly done, except the tests aren't (well, they aren't
automated yet).

The format differs between 32-bit and 64-bit Linux, unfortunately. So we
have two sets of test data (one for each), and here is where it came
from:

   - 64-bit: this comes from Watt, an actual machine.
   - 32-bit: from a qemu VM.

Both of these refer to bits in the capabilities/key file, no idea why
they did that... but they did. So its easier if our reverse-lookup table
combines them.

Easy enough to sort the EXPORT_OK and prototypes; the other two use each
so I'd have to change it. Not sure if there is any reason to (other than
reducing the diff size of generated code.)

Need prototypes for Perl to know those are function calls (when one
macro references another). Strict found this.