If there's no solution in progress, it should return MOVE_NO_EFFECT,
not MOVE_UNUSED.

If you clicked somewhere that had no effect (outside the grid or on a
square matching the colour of the top-left corner), interpret_move()
would return MOVE_NO_EFFECT (previously NULL) even though it had unset
ui->cursor.  So the keyboard cursor would remain visible until the
next window resize (or similar) when it would vanish.  Now
interpret_move() correctly returns MOVE_UI_UPDATE in these cases, so
the cursor vanishes immediately.

Clicking outside the grid hides the keyboard cursor, so it's not
MOVE_UNUSED like it usually is.

Flood's draw_tile() extravagantly uses up to eight rectangles to draw
separators around each tile.  This could be substantially improved,
but a particularly low-hanging optimisation is not do draw them when
the separator width is zero.

This at least means that Flood completes its initial drawing on my
test KaiOS device.

All the other constants named UI_* are special key names that can be
passed to midend_process_key(), but UI_UPDATE is a special return value
from the back-end interpret_move() function instead.  This renaming
makes the distinction clear and provides a naming convention for future
special return values from interpret_move().

These are similar to the existing pair configure() and custom_params()
in that get_prefs() returns an array of config_item describing a set
of dialog-box controls to present to the user, and set_prefs()
receives the same array with answers filled in and implements the
answers. But where configure() and custom_params() operate on a
game_params structure, the new pair operate on a game_ui, and are
intended to permit GUI configuration of all the settings I just moved
into that structure.

However, nothing actually _calls_ these routines yet. All I've done in
this commit is to add them to 'struct game' and implement them for the
functions that need them.

Also, config_item has new fields, permitting each config option to
define a machine-readable identifying keyword as well as the
user-facing description. For options of type C_CHOICES, each choice
also has a keyword. These keyword fields are only defined at all by
the new get_prefs() function - they're left uninitialised in existing
uses of the dialog system. The idea is to use them when writing out
the user's preferences into a configuration file on disk, although I
haven't actually done any of that work in this commit.

I'm about to move some of the bodgy getenv-based options so that they
become fields in game_ui. So these functions, which could previously
access those options directly via getenv, will now need to be given a
game_ui where they can look them up.

The majority of back-ends define encode_ui() to return NULL and
decode_ui() to do nothing.  This commit allows them to instead specify
the relevant function pointers as NULL, in which case the mid-end won't
try to call them.

I'm planning to add a parameter to decode_ui(), and if I'm going to have
to touch every back-end's version of decode_ui(), I may as well ensure
that most of them never need to be touched again.  And obviously
encode_ui() should go the same way for symmetry.