So far --preserve-merges would reset the HEAD to a (possibly rewritten)
parent of the rebased commit where possible, thus it was impossible to
sneak in extra commits at an earlier point in the history.

The most important change we make here is that we *always* cherry-pick
on top of the current HEAD, and introduce a new "branch" directive with
which we can manually request re-setting the HEAD to something else.

Merges then work by:
1. Finding the closest rebased or not-rewritten commit corresponding to
   each parent (by traversing history back otherwise)
2. Identify the one that corresponds to our HEAD (by traversing the
   rewritten history forwards).

Where step 2 can not come up with a suitable candidate, we pick parent 1
arbitrarily. Merges then work by essentially doing "git cherry-pick -m"
for the HEAD parent we identified previously.

Note that this ignores any rewrite changes coming in from the non-HEAD
branches for now. This could be extended by trying to apply diffs - but
that could make the whole process a good deal more messy, as we would now
have multiple merges going on per rebase step.

Quite a significant bug, as this means that rewritten original commits
weren't recognized properly. Thanks to John Morris for spotting this.