I'm sick of repeatedly adding and removing local changes to Recipe

when testing a new game, so here's a new architecture for the Recipe
file. mkfiles.pl now supports several new features:

 - an `!include' directive, which accepts wildcards
 - += to append to an existing object group definition
 - the ability to divert output to an arbitrary file.

So now each puzzle has a `.R' file containing a fragment of Recipe
code describing that puzzle, and the central Recipe does `!include
*.R' to construct the Makefiles. That way, I can keep as many
experimental half-finished puzzles lying around my working directory
as I like, and I won't have to keep reverting Recipe when I check in
any other changes.

As part of this change, list.c is no longer a version-controlled
file; it's now constructed by mkfiles.pl, so that it too can take
advantage of this mechanism.

[originally from svn r6781]

CHECKLST.txt

@@ -6,20 +6,25 @@ Things to remember when adding a new puzzle
 
 Write the source file for the new puzzle (duhh).
 
-Add it to Recipe in _four_ places:
- - the `ALL' definition, to ensure it is compiled into the OS X binary
- - as a GTK build target
- - as a Windows build target
- - in the Unix `make install' section at the bottom.
+Create a .R file for it which:
+ - defines a Recipe symbol for it if it requires auxiliary object
+   files
+ - adds it to the `ALL' definition, to ensure it is compiled into
+   the OS X binary
+ - adds it as a GTK build target
+ - adds it as a Windows build target
+ - adds auxiliary solver binaries if any
+ - adds it to $(GAMES) in the GTK makefile, for `make install'
+ - adds it to list.c for the OS X binary.
 
 If the puzzle is by a new author, modify the copyright notice in
 LICENCE and in puzzles.but. (Also in index.html, but that's listed
 below under website changes.)
 
-Add it to list.c so that the OS X binary will be able to select it
-from the menus. (Also, double-check that the game structure name in
-the source file has been renamed from `nullgame'. Actually compiling
-it on OS X would be a good way to check this, if convenient.)
+Double-check that the game structure name in the source file has
+been renamed from `nullgame', so that it'll work on OS X. Actually
+compiling it on OS X would be a good way to check this, if
+convenient.
 
 Add a documentation section in puzzles.but.