exit_nicely() exits from the guile thread before it gets a chance
to exit() from the process as a whole.

And there's really nothing for the reporting-code in exit_nicely
to actually report at this point, anyway.

This handler got broken when exit_nicely stopped actually triggering
an exit from the entire process and started just exiting the guile thread.

And, actually, it never exited with an error-status before--
which it does now.

Streams that start out connected to non-tty FDs default to fully-buffered
and retain that configuration after those underlying FDs are redirected,
which prevents the "need to run from an xterm" fix from actually working
unless we do something like this to reset the stream buffers.

Yet another of the niceties that comes out of just using guile's REPL
is that readline support is just figured out when building guile;
so by the time gnurobots is being built, readline support is either
there or it isn't--and even if our guile isn't readline-enabled,
we can still just run without readline (though, in practice,
I don't think I've ever seen a build of guile in the last 15 years
that didn't have readline...).

Move the GDK lock-management into the various arena action functions
so that we can release the lock _before_ sleeping in the guile thread,
allowing the GUI thread to update when the sleep starts
rather than when the sleep ends, so that the messages actually
stand a chance at remaining visible for something close to USLEEP_TIME--
rather than not showing until USLEEP_TIME has already expired.

Otherwise many of the updates get lost, e.g.:

	(while (robot-feel "space") (robot-move 1))

... never seems to actually spend any time with the "Robot feels ..."
messages visible onscreen between the "Robot moves.." messages.

Note also that this change allows the GUI to generally be much more
responsive to user interaction (e.g.: scrolling, selection/copy/paste)
while a robot program is running!

This gives _much_ more useful readline behavior,
since (ice-9 readline) actually knows how to autocomplete
based on the scheme environment, handle multi-line input, etc.;
and properly displays return values and error-messages,
and supports switching to different front-end programming languages
like ecmascript.

Note that we're keeping catch_handler so that we have a chance
of diagnosing problems that could _conceivably_ occur
when interacting with guile during bootstrap
(e.g.: missing readline support, changed REPL API...).

This avoids weird off-by-1 errors in the GUI counters at game end.