Fix race conditions in writing logs/lastbattle.txt

This fixes two race conditions in writing lastbattle.txt:

1) Previously, there could be several calls to `fs.writeFile` on
   lastbattle.txt queued at the same time. The order these would run in
   was undefined, so lastbattle.txt did not necessarily represent the
   actual last battle at any given time.

2) Since `fs.writeFile` clears the file before writing to it, it
   was possible to end up with an empty lastbattle.txt if the process
   terminated while the call to `fs.writeFile` was being processed
   asynchronously. This commit fixes the issue by writing to a file
   named logs/lastbattle.txt.0 and then renaming that file to
   logs/lastbattle.txt. On POSIX, `rename` changes the target
   file's link to point to the soruce file (which is an atomic
   operation). Thus, this removes the possibility of ending up with
   an empty logs/lastbattle.txt on POSIX.

   Unfortunately, on Windows, `rename` will throw an error if the
   target file exists, which it will. In case of an error, this
   code still writes to logs/lastbattle.txt, but in a way that
   has a possibility of a race condition. As such, race conditions
   in writing to logs/lastbattle.txt are still possible on Windows, but
   they are fixed on POSIX at least.