[Storage] Add storage_compatibility_version to control for what version the DB has to be serialized.

[Tishj]

The idea behind the storage compatibility version is that we want to be able to add serialization, without losing the ability for forwards compatibility.

What inspired this functionality (and is introduces by this PR as well) is the ability to serialize CatalogEntry dependencies.
Because we won't rebind entries on load of a database anymore (think indexes, default values, views etc..), we also won't rediscover dependencies, as that is done during binding.

We do not serialize them by default currently.
Using `storage_compatibility_version='v0.10.3' you can opt-in to this, it will be the default in a future release.

storage_compatibility_version

This is a new setting on the DBConfig, it takes a VARCHAR value in the form of: v<major>.<minor>.<patch> or latest
The string internally gets mapped to a serialization version, which is checked at serialization time.

The generate_serialization.py was updated to conditionally serialize items that have been marked with a version field based on this setting.

[carlopi]

I think this is a cool feature to have, but I worry a bit of the ramifications of this, in particular that using this setting will allow user to lose data / constraint / information and produce a DB file that will not keep track of the fact that this has been produced while being instructed to skip some serialization.

In particular, how can you tell given a db file on your machine whether it's the 'complete' DB version or some limited version of it?

One proposal that could handle this goals could be having this setting be at the attached database level, and with this information serialized to the header of the Database file.
Basically something like:
ATTACH file.db (STORAGE_COMPAT v0.10.2) -> create file.db, write STORAGE_COMPAT to it, and will be used for subsequent writes to file (if the version is aware of storage_compat setting, otherwise we assume it has to be compatible)
ATTACH file.db on an existing file, inherits the STORAGE_COMPAT version stored to the file (defaults to no constraint being there)

This achieve a few things: no impact on the running database (I feel strange that storage_compatibility_version + PRAGMA verify_serializer allows you to change results of computed queries), consistent compatibility for a given db file (even when iterating opening-write-close-open-write-close the setting is owned by the DB), and allows easier migration (basically attach DB 1, attach DB 2 with storage_compat, copy from one to other).

[Mytherin]

Having the target serialization version attached to a database file makes sense to me, but can likely be added later. (1) we still need a default version in case none is specified, this setting can serve as that default setting, and (2) we might also need this for serialization of e.g. logical plans to e.g. JSON, which does not involve an attached database.

[Mytherin]

Thanks!