Do not build content type revisions on drafts of stale sets #2588

Part of #2415 (F-SCH). A follow-up from the review of #2520 (SCH-05).

A content type revision may be based on a draft while a set that can still publish proposes it. "Can still publish" is read from the set's state only. A set whose operation has gone stale can never publish, but it counts as live until someone rejects it. Basing a revision on its draft is accepted, and the new set then fails at publish with base_version_stale.

Scenario: sets S1 and S2 both revise product from v1, giving v2 and v3. S1 publishes, so S2 is stale. A revision based on v3 into a new set is accepted, and that set can never publish.

Scope

• Treat a draft as a base only while its set can still publish over the version that is live. Today that means its operation's base is the published version (or, for a create, nothing is published), or it builds on a draft that passes the same test. Revert can move the published version back, so the test is made when the revision is written, not stored.
• The same test for which drafts count as live in the reference checks (LiveDefinitionsAsync).
• Once approved → rejected exists (the follow-up from the post-merge review of Add atomic change set publish #2482), a person can clear a stale set. The desk could flag stale sets (F-DSK F-DSK: Review desk as the home screen #2422).

Acceptance

• In the scenario above, the revision based on v3 is refused with version_conflict, naming the published version to revise.
• A chain of open drafts on top of the published version is still accepted.
• All of the above passes on SQLite and PostgreSQL.