storage: consider relaxing need for blocking cluster versions when performing Pebble migrations

**Is your feature request related to a problem? Please describe.**

In instances where we need to ensure that all nodes in a cluster have Pebble stores satisfying some precondition (e.g. all "old" SSTables have been re-written; tables with split user keys have been compacted), we typically use two _cluster_ versions. The first is used as a "mark" phase in one _Cockroach version_ `V`. A second is then introduced in a subsequent release `V+n` (where `n` is usually `1`) that blocks waiting for all the marked items to be processed.

This blocking operation in the version `V+n` is likely overly conservative. Instead of holding up the progression through subsequent cluster versions, the precondition could be incorporated into a background job. The completion of said job would then become a precondition for the finalization of the Cockroach version `V+n`.

**Describe the solution you'd like**

Investigate whether we can use the job framework and preconditions to accomplish the same goal, rather than employing a second cluster version.

**Describe alternatives you've considered**

Keep things the way they are (i.e. two cluster versions), at the expense of having a potentially long running Pebble background operation preventing other Cockroach migrations from occurring.

**Additional context**

More context in this [internal thread](https://cockroachlabs.slack.com/archives/CAC6K3SLU/p1675873205676909).

Jira issue: CRDB-24351

The issue names no files or tests. Start by tracing existing two-cluster-version Pebble migration patterns and how the job framework handles preconditions; the linked internal thread may provide context. Done means determining whether job completion can gate Cockroach version finalization without blocking later migrations, and documenting the constraints or a concrete approach.

Written by the indexing model from the issue text.