Upgrade Database and Character Creation Screen

[michaelchessall]

Changes

Add tables characters, charactersaves, instances, worldsaves
Remove limbo tables, turfs and areas tables.

Adds the functionality for multiple world saves, character saves and other types of saved data to be bundled and put into the things, things_var and list_elements tables. The process of saving anything is unified under the sql serializer, and the same process is applicable for any type of saved data.

Any time something is saved to the database, that save is marked by an 'InstanceID' in the instances table. this InstanceID is linked to things, things_var and list_elements so the instance can be saved and loaded just like the prior world save. When a world save finishes, the InstanceID is added to the worldsaves table and when the server is rebooted it chooses the newest entry of the worldsave table to load.

When a character is created, an entry is made in the characters table that generated a CharacterID. this ID is the 'key' that is unique to the character and never changes. When a character finishes saving, it makes an entry in the characterssaves table that links an InstanceID to the CharacterID. The character status is updated anytime the character is saved, letting the DB know whether the character should exist in the game world, or in cryo, or if its deleted.

Past Instances of worldsaves or character saves can continue to exist on the DB without doing fatal damage, but bloating the total amount of saved entities will presumably slow down queries. i dont know to what extent that would be a problem, or at what point it starts to be. It would be pretty easy to implement a system to wipe out older data, while keeping a 1-3 instance backup directly on the DB. It would be possible to do that with procedures and functions built into the DB so it doesnt slow down the program. I haven't looked into that yet.

The areas and z_levels tables have been removed and that functionality is now taken care of by the instances table. every instance tracked a 'head', which is a thing_id which corresponds to a /datum/ that holds things like z_levels, and areas data.
the 'head' has a function for character saving/loading as well, and any other type of future save operation can use the 'head' to store complex metadata

the bottom line benefit is, world saves can be made and verified as working before the old save is deleted. Characters wont change slots, or overwrite, or vanish. The limbo system has been folded into the sql_serializer which worked a lot more consistently. Character saving is a groundwork that shows how anything, from personal storage lockers to parked shuttles can be implemented into the instance system.

Limitations

reference only vars don't work in the new system. persistence_id is NOT permanent and NOT unique. persistence_id and InstanceID combine to make a unique key, but only when referring to the database. Bottom line is the Persistence_ID only has meaning within the confines of a particular instance, so a reference only variable does not function. The only case of a reference only variable i've replaced with a better solution for tracking cryobeds.

I don't understand the point in ref saving and I have disabled/removed it wherever i can. It seems pointless, but its either laying groundwork for something i dont know about or doing something i dont understand. In either case, saving memory references in the new design where A. the game never has to delete any data from the database, any deletion is optional B. instances are meant to be saved/loaded all at once. The fastest way to save is to cache all the data and commit it in as big of chunks as we can. stopping and starting doesn't work with that. the fastest way to load is to retrieve all the data and cache it all, only worrying about the relationship between the data when building from the cache. Again that requires the entire data to be read as one large operation.

PersistenceID has turned into a half of a key, which at runtime is neither unique nor permanent. therefore get_object_from_pid() is nonfunctional. I dont think it was used for anything.

[PsyCommando]

We'll need to revisit this at one point once we can get things working again.