multiple staging support

Currently the mergebot assumes each branch only has one staging going on, and this assumption is leveraged in several places (usually by checking a branch's active_staging_id for information).

This is likely non-trivial, but would be a requirement for advanced staging modes e.g.

• incremental staging (#951)
• optimistic concurrent staging (create staging 2 on top of staging 1 if there are enough PRs waiting)
• concurrent split staging (#497) as well as pessimistic concurrent staging (the same without a split, assumes the current staging is going to fail)
• pessimistic splitting (stages a staging and its splits at the same time such that one of the splits can be merged if the main staging fails)
• ...

Changing this would likely require some sort of intermediate staging strategy object, which can bundle a bunch of stagings and provides relevant query operations. Note that this also impacts batches and PRs as we dereference their stagings e.g. to cancel the current staging if they're part of that on r- or w/e.

Shower thoughts:

• strategy needs to be on the project, with links to branches I guess? Stagings (the representation) should probably stop doing staging jobs and delegate to strategy records in order to handle variable geometries e.g. concurrent stagings, queue, ...
• strategy probably needs to provide some templates in order to render stagings on the home page and in the branch list

Start by tracing mergebot uses of a branch's active_staging_id, then inspect how stagings, batches, and pull requests dereference each other. Review the staging representation and the project, branch, home-page, and branch-list strategy concerns described in the issue. Done means the model and queries support multiple stagings and the affected cancellation and rendering flows are updated.