Auto-migrate: Allow adding new variants at the tail

[Centril]

Description of Changes

To the auto-migrate machinery, detection of the case where a sum type is extended with additional variants and where the sum type as a whole does not grow in size. This then results in a new datastore call alter_table_row_type which independently checks for "soundness" of using the new row type for the existing rows. This call, being a schema altering one, is handled, in terms of transactionality, the same way that e.g., create_index is, by adding a pending schema change.

API and ABI breaking changes

None

Expected complexity level and risk

3 - this is fairly sensitive logic that is critical to get right so that we don't cause UB and problems down the line.

Testing

• The datastore functionality is independently tested to see that it works and for transactionality.
• The datastore API alter_table_access was untested and is now tested also in terms of transactionality.
• The auto-migration logic is tested comprehensively both for success and failure.
• A smoketest is amended to have an integration test as well.

[gefjon]

Minor comment-ey nits, and a significant logic concern: I think that renaming enum variants or field names should require a manual migration. There's no technical reason why we have to do this, but I think that using ordering as a source of truth is a surprising and footgun-ey behavior.

[gefjon]

Beautiful, thanks!