Create db.h and db schema update logic

[rogersm]

First path for the Persistence solution.

1. It moves the db definitions to a different include file (db.h)
2. Updates db_migrate() in db.c so guildmud updates the db to the latest release on startup.
3. As part of (2) we add to the database the NEXT_ID filed to have a single generator of id for all the objects the mud will manage. This will be used in the following persistence PR.

[zachflower]

I like this, and was almost exactly what I had in mind for a migration strategy. What do you think about wrapping the actual migration runner in a TRANSACTION, so we don't get half-finished migrations?

[rogersm]

@zachflower That's a clever idea. I had in mind to have simple actions in the schema upgrade SQL action without need of any transaction, but I have to admit a TRANSACTION block will not hurt. I'll update the code it to include it.

EDIT.

I've been thinking about it... what do you have in mind exactly? A TRANSACTION/COMMIT block for each step or to have a single TRANSACTION/COMMIT for all the steps?

I see pros/cons for each option and I think a TRANSACTION/COMMIT for all steps makes more sense.

[zachflower]

This all looks great @rogersm! I think the TRANSACTION/COMMIT for the entire migration was the way to go, rather than for each command. If any point during the process fails, the entire thing gets rolled back, which will protect us against potential failed dependent migrations.