Internal storage schema migration

[rnewman]

A number of changes in the issue stack will require changes to the storage schema (that is: the raw SQL schema itself).

Some are: #69, #67, #44, #45, #51, #32, #31, #29, and of course #33.

We should make sure we have a good, solid place to implement these migrations across Datomish versions.

[rnewman]

This, #125, and #124 are related.

When we create a database, we do the following:

• Open and PRAGMA the connection.
• Check the user version, creating SQL tables and views. This is in sqlite_schema.cljc.
• Then, separately (and non-transactionally until Error during bootstrap leaves database unopenable #125 is fixed) check whether the transaction log is empty. If it is, transact bootstrap datoms.

This is problematic in several ways:

• A change in the bootstrap datoms can't easily be detected and applied: <bootstrapped? is a boolean.
• A relationship between the bootstrap data and the SQL schema can't be made: e.g., updating part ranges.
• One cannot transactionally update the SQL schema and the bootstrapped schema.

I intend to do the following:

• Tie the bootstrap schema to the SQL user_version.
• Apply the SQL schema and upgrades in the same transaction as the bootstrap schema application.
• Add a hook for applying changes to the bootstrap schema by user_version.

That is: now we've added some base schema items, we'll upgrade from v1 to v2 by transacting the new attributes and UPDATEing the parts table.

[rnewman]

Keeping this open to track the idea in Mentat.