Add a new script to perform a 'merging rebase'

Add a new script to perform a 'merging rebase'

We introduced the concept of a 'rebasing merge' earlier, which simply
meant that in addition to rebasing all of our commits on top of
git.git's 'next' branch, we also performed a merge with the previous
state of the current branch using the 'ours' strategy, so that things
still would fast-forward.

This approach has quite a few shortcomings, not the least of which are:
it is hard to find the commits that need to be rebased (because of the
merge, all previous versions of the commits are part of the history),
and we could not take advantage of rebase's --autosquash option.

Instead, let's perform the merge with the 'ours' strategy _before_
applying all the patches.

That way, the commits to be rebased in the future can be obtained using
the commit range <merge>.. where <merge> is simply the most recent start
of a merging rebase.

Since the introduction of the 'exec' command (thanks Matthieu Moy), the
implementation is very easy: we only have to inject two commands at the
start of the edit script to initialize the merging rebase.

There is a cunning hack in the script to make use of previous rebasing
merges (as opposed to merging rebases): we now require a single commit
as base for use by 'git rebase -i'. Since the rebasing merges only
provide a pair of bases, not a single base, we make a throw-away merge
commit combining those two bases into a single one.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>