Refactor submap saving

This is the foundation for incremental submap saving/loading.
It will load the monolithic maps.txt file if it's present and then delete it.  Only when loading the old file, it will immediately save so it can have all the transitional logic in one spot.

To explain what's happening a bit:
Previously (since whales days), there was one maps.txt file that stored EVERY submap, and was loaded and saved all at once.  As a side effect of this all submaps were loaded at game start and kept in memory indefinitely.  From what I can tell from git archaeology, the reason for this was that Windows was very unhappy with directories with very large numbers of files, and would choke on save/load if you explored too far (generating too many submaps).
What I've done here is changed the submap save/load logic to save 4 submaps per file, the reason for which is this is the unit in which submaps are created, a 2x2 square, corresponding to a single overmap tile, for example the shelter, or a house.
To keep windows from freaking out once you've explored a few million submaps*, the game splits the submap quads up into subdirectories based on global map coordinates, with a maximum of 32x32 (1024) files in a subdirectory.  If even that number turns out to be too large, that number is easily adjusted.
A side issue is that at some point a map of strings to integer values for terrain, furniture, and traps was added to the maps.txt file.  This now lives in a file called map.key, and is loaded before the rest of the map data.  This also holds the current verion of the map data, so if we make changes, encountering an old version in this file can trigger converting all the map data to the new format.
The new directory structure looks something like:

```
save/<worldname>/maps/map.key
                     \1.0.0/126.60.0.map
                           \126.56.0.map
                           \repeat up to 1030 more files
                     \1.1.0/126.64.0.map
                           \126.66.0.map
                           /...etc
```

The next step is to code up a system where the game only loads submaps it needs.  The step after that is to have the game identify submaps it doesn't need anymore, and write them back out to disk.  At that point game performance should be completely decoupled from total explored area, with the sole exception of having to read and write every submap when loading an old map version.

*I'm not being facetious, a million submaps shouldn't pose any problems once this is done.