Adding option to save and load state by timestamp

### Problem

> Save oldest state doesn't work. If 8 slots are already being used, it just saves to slot -1.

> saving to slot -1 when holding down the hotkey.

The flaws that allowed "GetEmptySlot" to return -1 (occur when "savedStates.size() < 8" and 1-8 is found in the map (previously the disk)) is

* two files were allowed to have the same mtime in a map so that the duplicate is dropped from the "savedStates" map but file 1-8 are on disk
* the state file list was read twice in "SaveFirstSaved" between which it might change so that GetEmptySlot is called to read the disk and find that 1-8 is on disk


Another flaw that's fixed by waiting for a state to be written before the function return (and allow another state to be saved) is

* the possibility to queue >8 saves before all 8 state files are written (where overwrite will occur regardless of timestamp)

### Limitation

> it still doesn't save in the proper order when using it too quickly

>[16:00] <_RachelB> JPeterson: ok, well my biggest complaint is still that when saving more frequently than once per second, it seemingly chooses at random which to save/load

Random is an imprecise description, if multiple states have the same mtime the state with the lowest ordinal number is overwritten or loaded

It might be because the mtime resolution <http://en.wikipedia.org/wiki/Stat_(system_call)#Granularity_of_mtime.2C_etc.> is 1 s

This can't be fixed without adding subsecond metadata to the state. That's not meaningful because

* it's unlikely that saving a state takes less than 1 s (even when assuming writing state to SSD media)
* it's not important if that occurs

>[16:22] <_RachelB> it takes way less than a second
>[16:23] <_RachelB> at least for me, while indeed, writing to an ssd

Hold the "Save Oldest State" key to save as fast as possible and print the output from

	ls --time-style=full-iso -gohv User/StateSaves|grep GCTE51

to inform me how many states you can save with the same mtime. My output is

	-rw-r--r-- 1  26M 2013-04-29 19:40:02.707193000 +0200 GCTE51.s01
	-rw-r--r-- 1  26M 2013-04-29 19:40:03.502238400 +0200 GCTE51.s02
	-rw-r--r-- 1  26M 2013-04-29 19:39:58.931977000 +0200 GCTE51.s03
	-rw-r--r-- 1  26M 2013-04-29 19:39:59.554012600 +0200 GCTE51.s04
	-rw-r--r-- 1  26M 2013-04-29 19:40:00.201049600 +0200 GCTE51.s05
	-rw-r--r-- 1  26M 2013-04-29 19:40:00.824085300 +0200 GCTE51.s06
	-rw-r--r-- 1  26M 2013-04-29 19:40:01.452121200 +0200 GCTE51.s07
	-rw-r--r-- 1  26M 2013-04-29 19:40:02.081157200 +0200 GCTE51.s08

>[16:32] <_RachelB> i'm on windows

bash can be run in cmd.exe. The cmd.exe equivalent `dir` can't display seconds

>[16:32] <_RachelB> but i already timed it using std::Timer, and average time is about 320 ms, so up to 4

Print the output anyway because this might be without the "wait" code added in this version

What's the scenario where there's a benefit with subsecond states?