NH4: Don't reverse trap chain order upon restore

This causes the replay code to spuriously report a desync when
rewinding if a level has at least two traps on it.

Don't reverse order of trap chain upon save and restore
Alex Smith <ais523@bham.ac.uk>
0fc1051e98ce2315e27baa09f199b3d39fbbda30
Fix replay desync warning due to timer_id

The ID for timers is assigned from an incrementing static int which
wasn't reset, saved or restored with games, causing the command-driven
replays to use different IDs from the ones in the logged save diffs, in
turn causing a desync warning to be displayed.

This bug also exists in NetHack4.

Closes #77 on GitHub.
NH4: Save null shopkeeper bills explicitly

Without this, shopkeepers with null bill pointers could be saved with a
pointer-based value, at least in theory.  In practice, shopkeeper bill
pointers are only set to null when they're dead and about to be purged.
In any case, this helps prevent bogus replay desync warnings with the
new diff-logged replay system.

Compared to NetHack4, this omits the byte-numbering in the monster
restoring code.

Save empty shopkeeper bills correctly
Alex Smith <ais523@bham.ac.uk>
24c8844e9e1506d83253d532ad3a8b80882d47dc
NH4: Don't call check_special_room on game restore

From NetHack4:

"As far as I can tell, it's a no-op; there isn't a matching call in
vanilla, and all it does is set urooms0 to urooms.  urooms0 is ignored
everywhere except inside check_special_room anyway; and saving and
restoring shouldn't cause you to leave or enter a room, so nothing
should happen.  The change to urooms0 confuses the desync detector, so
it's better to remove this call than leave it in."

Don't call check_special_room on game restore
Alex Smith <ais523@bham.ac.uk>
60454da37c4eccb920ee4a241474e31febace68b
Save and restore u.ubirthday to fix replays

Without this, restoring a game or rewinding in a replay would cause
u.ubirthday to be set to 0 instead of time the character was created.
This affects:

 * which bones file is chosen to be saved or loaded in the current
   level's bones pool
 * which ant type occupies any given anthole
 * the randomized creator deity name
 * the erosion applied to T-shirt labels when reading them
 * the cost of gems in a shop
 * which name is randomly chosen for shopkeepers

The last one was triggering a diff log replay desync warning when
rewinding a replay and advancing to a level a shopkeeper was created on,
since the name chosen by the replay was different from the one in the
logged diff.  The anthole population and gem costs would almost
certainly cause game-affecting desyncs as well.

This fix assumes 64 bits is enough to store time_t, since the C99
standard (ISO/IEC 9899/1999, n1256.pdf) states "the range and precision
of times representable in clock_t and time_t are implementation-
defined."  (It's 4 bytes large on my 32-bit Linux system.)  NitroHack
already assumes this via storing the result of time(NULL) in the
unsigned long long turntime variable.

The character's birthday is already stored in the log header, but due to
the heavily-stateful nature of log reading and the mid-log recovery of
the new logged diff replay system, it is easier and more reliable to
save and restore it with the rest of struct you.

NetHack4 partially addresses this in the following commits (code not
used here):

 * bed7cae11304dd0d5c2679c9f2bc5461cc3fb877
 * f893eb81fb405bcbe8ae623729351245f06cfd77

However, they only fix this for manually-loaded games, not for rewinding
in replays, so this bug also exists in NetHack4.
Prevent lock-up when pruning message history

nh_view_replay_step() may issue print_message(moves, "") with moves == 0
if the new logged diff replay system fails while restoring a game,
leading to an infinite loop in prune_messages() in the interface.

This bug also exists in NetHack4.