Gate each transaction action by supported table format versions

[dannycjones]

Is your feature request related to a problem or challenge?

Transaction actions (RowDelta, RewriteFiles, Append) each have logic dependent on the table format version - specifically, their validations. Thus, as we adopt new table format version support we need a way to avoid incorrect behaviors being applied to newer table formats.

Additionally, I'd like to avoid making adopting V3 support a "big bang" change and allow for incremental support.

Describe the solution you'd like

I propose that we add a method to TransactionAction which specifies which table format versions it supports. Thus, one code change can be "update appends to support V3" merged in isolation from, for example, RewriteFiles which needs to check no new manifest delete vectors were applied during its rewrite.

Willingness to contribute

I can contribute to this feature independently

[dannycjones]

Related: #2411, #2269

[dannycjones]

I've been giving this a little more thought. It's not necessarily going to be as simple as "do I support V2 and V3" because there may only be partial support.

For example, V3 introduced delete vectors and row lineage (among other things). Validations for something like RewriteDataFiles will require to validate there were no new deletes (i.e. positional, equality, or vector) as well as ensure that row lineage is updated for the new metadata graph. If only one was implemented, we'd either be unable to use the action as it doesn't 'support V3' or it can mark it as supported but then must be able to reject or avoid committing data it doesn't understand.

I don't think this is an argument against including a way to specify that an action has been updated for the the next table format version, but this requires more thinking.