stacked merge requests #87

A merge request whose target branch is the source branch of another open merge request in the same repository is stacked on it. Targeting such a branch already works today; what is missing is everything that makes the stack usable after the bottom merges.

Design:

• Derived, not stored. B is stacked on A when B.target_ref == A.source_ref, both open, same repository. No new column, no new flag on mr create; the output of mr create says stacked on !A when it applies.
• mr show gains stacked_on (number, title, state) and stacked (the open merge requests targeting this one's source branch). mr list rows gain stacked_on. The web merge request page shows "stacked on !A" in the header and "!B builds on this" below it.
• When A merges, every open merge request targeting A.source_ref is retargeted to A.target_ref with a system comment naming the merge, before anything removes the source branch. Reviews are kept: the diff against the new target is the diff it was approved against.
• That holds only when A's commits reach the target unchanged. Merging A with --strategy squash or rebase while it has stacked merge requests is refused with the stack named: merge with ff or merge, or merge the stack top-down into A first.
• Closing A without merging leaves the stack alone; its branch still exists.
• Merging B into A's branch while A is open is allowed. It collapses B into A, and A's head updates as on any push to its branch.

Test: a three-deep stack over SSH, merged bottom-up, each retarget landing with its comment and its reviews intact; the squash refusal; and the real thing, the v1.6.0 issues implemented as one stack of merge requests and merged in order.

Parity: a merge request row "stacked merge requests", cli yes, web read-only, ios no.