Make the first stable release forward-compatible with planned state changes

[teor2345]

Motivation

We're going to make some state changes that are backward-compatible as part of the "fast spendability" RPCs in #6642. Later Zebra versions can already open and read earlier states and update them, without changing the major version of the state.

But to make them forward-compatible (earlier versions can read later states), we need to make some minor changes.

Scheduling

Ideally, these changes should be made before the stable release, so we can guarantee that any stable Zebra version can open any stable state.

Compatibility Issues

RocksDB requires all column families to be listed when we open the state read-write:

• use list_cf() so earlier Zebra versions can open column families added in later state versions

In #4784, we will delete some duplicate sapling and orchard tree states:

• use zs_prev_key_value_back_from() to look up sapling and orchard note commitment trees
• sprout already deletes its old note commitment trees when it adds a new one, because historical roots are looked up by their hash

Version tracking:

• add a minor version 25.1 to the state, and call the previous version 25.0

Testing

I think we should support these changes on a best-effort basis, and just use our existing tests.