It's silly to have every puzzle using latin.c separately specify in
its .R file the list of additional modules that latin.c depends on, or
for that matter to have them all have to separately know how to adjust
that for the STANDALONE_SOLVER mode of latin.c.

So I've centralised a new pair of definitions into the core Recipe
file, called LATIN and LATIN_SOLVER, and now a client of latin.c need
only ask for that to get all the necessary dependencies too.

Also, while I'm here, I've moved the non-puzzle-specific 'latincheck'
test program out of unequal.R into the central Recipe.

It was getting conscientiously escaped by the new webpage.pl :-) but
in any case it's better to have the puzzle descriptions be plain text
usable in any context.

More sensible to bring all the pieces of per-puzzle descriptive text
together into one place, so they can be easily reused everywhere
they're needed.

install the actual games, not the auxiliary binaries or nullgame.

[originally from svn r9887]

to it giving each game's "internal" name (as seen in the source file,
.R etc) and also a brief description of the game. The idea of the
latter is that it should be usable as a comment field in .desktop
files and similar.

[originally from svn r9858]

defining it centrally per port, I think it's neater to define it for
each puzzle when adding that puzzle to the ALL list - because those
front ends which take -DCOMBINED are precisely those which use ALL.
In particular, this change opens up the possibility of compiling
both individual puzzles _and_ a combined monolith within the same
makefile.

[originally from svn r8178]

This means that puzzles.rc2 is always included in all Windows and
PocketPC builds, which in turn means that I should be able to start
filling it full of VERSIONINFO and have that reliably included as
well.

[originally from svn r7339]

[originally from svn r7319]

infrastructure to the mkfiles.pl framework for the convenience of
the build script: it generates `wingames.lst', a list of the Windows
binaries which are ship-worthy games as opposed to nullgame or
command-line auxiliary programs.

[originally from svn r7206]

[originally from svn r7101]