Process change: allow experimental Table features in Lance

[wjones127]

In the file-format, we can add unstable features to the main branch by adding them to the next version of the file format. We only vote to stabilize them when we decide to stabilize the next version of the file format. This makes it really easy to experiment and test out new encodings, without fully committing to stability.

We don't have a parallel mechanism for the table format. The table format is "versioned" via feature flags (writer_feature_flags and reader_feature_flags). But there's no unstable state of a feature flag: it either exists or doesn't. Some features have implicitly been called unstable. But realistically we have to support backwards compatibility.

Why not feature branches? We could develop large table format changes on special branches. But this has a cost: the maintainer of that branch needs to regularly rebase on main. If they are developing something that cuts across a lot of systems (such as stable row id or transaction v2), it means a lot of invasive rebasing. While branches isolate the main branch from any changes due to an experiment, they make it hard to keep the experimental feature ready to be merged into main in the end. If it's something we truly care about adding to the format, we don't want this friction.

Why not just use the writer_feature_flags and reader_feature_flags as-is? First, if we decide to abandon the experimental feature, we'll have forever lost that bit in the flags. Second, there's no way to differentiate between "experimental version of dataset" and "stable version of dataset", which could cause some issues reading. The latter is also a problem with the file-format system, and it's a primary concern.

I propose adding a new flag FLAG_EXPERIMENTAL, which enables two new proto fields: repeated string experimental_reader_features and repeated string experimental_writer_features. This means we only need one flag to state there might be experimental features, and then the features are in a separate free form field. Most of the times, those will be empty and omitted from the protobuf message. But they allow adopting and dropping experimental flags as needed.

The full proposal is in this PR: #7646