kvserver: sep-raft-log: introduce struct for optional two engines

[tbg]

In a separate raft log setup, we have two engines across which a Replica's data is partitioned. We should leverage the type system to make sure these two engines can't accidentally be swapped, and introduce a struct that holds them which can serve as the main entry point for documentation of invariants and concepts. Straw man:

// Big comment here
type Storage {
  LogEngine LogEngine // if nil, not separate raft log
  StateEngine StateEngine
}

// Accessors/helpers to make it easier to support both configurations.

Epic: CRDB-220

Jira issue: CRDB-22236

[blathers-crl]

cc @cockroachdb/replication

[tbg]

edit: oops meant to post this over on #93898.

---

The interesting question here is: why does the RangeTombstoneKey have to be on the state machine engine?

To see this, consider a snapshot application that also subsumes an adjacent replica r2. We need to replace it with the snapshot and also remove it, but atomically. If we have the RangeTombstoneKey on the log engine, we need extra steps to make the deletion safe (or we end up with the tombstone but the data still there, so then we risk cleaning it up even though the snapshot never applied, possibly breaking merge-related invariants, or we delete the data but then don't have a tombstone for it, making the right-hand side look like an uninitialized replica).

[tbg]

We can call this done - the Store has separated fields for the engines and accessors for them.