Workaround signal misfires that led to crash

Even though the original ChessGame is always destroyed immediately after
the creation of a new one (no other reference to it exists), the signals
we connected to the original game may be nonetheless fired by the NEW
game object. This must be a bug in Vala signals.

https://bugzilla.gnome.org/show_bug.cgi?id=732067
Fix build

Oops, this was cherry-picked from gnome-3-10 and not all of these
signals still exist.

Turns out the signal misfires are a Vala codegen mistake when it creates
a fundamental type, and can be avoided by making game a GObject.
Always enable New Game on game over

If something goes wrong with the engine before the first move, then the
user needs to be able to press New Game.
Fix Undo before engine moves

Since I added a delay before telling the engine to move, this opened a
window where the engine could become desynced if you use Undo before it
receives a move request, since during this time, the ChessEngine class
thinks it's still the human player's turn
Do not enable pause action when browsing history

If a game is already completed, moving around in history could cause the
pause button to become sensitive.
Fix desync when viewing history on engine's turn

If you use the history buttons while the engine was thinking, we would
get an "oops! something has gone wrong" once the engine decided to move.
Return view to the present when engine moves

If we are looking back in history, force the view to return to the
present as soon as the engine moves.
ChessGame: do not complete move if game is over

Fixes clock unpausing when using Undo after gnuchess has decided to
report a move but before it has actually done so (which is no longer
possible after the previous commit, anyway)
Prepare 3.12.3