Last November in commit 08365fb260ae6e3 I added a VERSIONINFO resource
to the Windows puzzle binaries, with three of the four integer
components of the binary version number taken from the year, month and
day of the build date. The header file #define of those integers was
made by a Perl one-liner which just split up $(!builddate) into the
right groups of digits.

But it didn't trim leading zeroes. So the build failed today because
the month component of the version number was '08', which isn't a
valid C integer literal (the leading 0 means octal, but 8 isn't an
octal digit), and presumably therefore not valid according to llvm-rc
either. I have to assume that the previous months have all worked
because 01, ..., 07 _are_ valid octal integer literals and still mean
the right things.

I'm not 100% satisfied with this explanation, because surely the same
argument applied to the day field should have meant my builds failed
on the 8th and 9th of every month since I added this code last
November! But I don't have any evidence left over to show why it
_didn't_ fail. Perhaps I've upgraded llvm-rc past a relevant bug fix
in the last month, or something.

The foosolver.exe binaries aren't delivered out of the end of
Buildscr, so there's no point wasting time on signing them. Signing is
slow in wall-clock time (you have to wait for a timestamp server), so
this should significantly reduce overall build time.

This includes the textual version number in its existing
form (yyyymmdd followed by an abbreviated git hash). The four-part
binary version is set to 1 followed by year, month and day; if I ever
want to change that, I can increment the initial 1.

FileDescription is taken from the existing DESCRIPTION string provided
to each puzzle() statement in CMakeLists.txt.

This means that puzzles.rc now always defines at least one resource,
so we can remove the workaround for MinGW's windres not being able to
cope with an empty .rc file, which added a dummy resource in the
absence of an icon.

The KaiOS build includes compiled versions of various Emscripten library
files.  These are generally under the MIT licence like Puzzles itself.
The MIT licence requires that the licence, and the copyright notice, be
"included in all copies or substantial portions of the Software."

Since each KaiOS package includes the full manual, which already
contains the licence for Puzzles itself, adding the copyright notices
there seems like the best approach.  I've done this by providing an
additional input file that contains the licences for source files used
by a current Emscripten build.  More automation might be nice, but the
set of copyright notices is unlikely to change very much.  There are
basically one for Emscripten, one for musl, and a few for odd bits of
third-party code embedded in musl.

I've just enabled a warning that only fires in that mode, so we need
to keep running the build in that configuration to ensure further
instances of the warning aren't introduced.

Simon's build infrastructure doesn't have Halibut available on the same
system as Emscripten, which means that the normal KaiOS build can't
build the documentation.  At present, though, the version of the
documentation that's built for the Web page is perfectly acceptable for
KaiOS as well, so we may as well seed the KaiOS build directory with
that.

This is slightly unfortunate because it means that it's difficult to
make changes only to the KaiOS documentation, and I'd like to be able to
do that eventually.  We can cross that bridge once Halibut has the
features I want.

These are currently treated as just another JavaScript build, so they
don't have their own variable to turn them off.

Also a way around it, at least in Firefox.

Only just remembered that this was generated by my build scripts.