Fix t3409.5

The idea was to test whether the rebase of M onto A2 (while preserving
the merge commits) in this graph works:

	A1 - B1 - M
	   \    /
	     A2

The original problem fixed in 12bf8283(rebase -i -p: include
non-first-parent commits in todo list) was that B1 was dropped.

However, the test was overzealous in assuming that M needs to be
preserved: when rebasing, in effect, B1 and M onto A2, B1 should
actually be cherry-picked, and M no longer be necessary. This is the
behavior of the upcoming new 'rebase -i -p'.

So let's test that the relevant commits are all there, but skip the test
whether the merge is still there (that would need to be a forced
non-fast-forward merge if B1 is rebased).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make t3411.2 future-proof

This test used to test implementation details: the FAKE_LINES hack works
only for a very specific layout of the edit script, a layout we will
change in the upcoming 'rebase -i -p' rework.

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

This test case assumed that preserving merges would preserve a certain
set of merged branches, but it should have allowed for more commits to
be rebased.

In particular, the scenario was this:

	A - B - E - F - G
	  \   \       /
	    H   C - D

and after rebasing G from C onto H, it expected the history to look like
this:

	A - B - E - F - G
	  \           /
            H - D' --

while the upcoming 'rebase -i -p' will write it into:

	A - H - E' - F' - G
	      \         /
	        D' ----

Since B is reachable from C, it should not have been part of the rebased
history, therefore the original test whether the first parent of G is the
original F is arguably wrong.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rebase -i: introduce the 'label' and 'goto' commands

In edit scripts, 'label <nick>' will mark the then-current commit for
later use with 'goto <nick>' (which will reset the HEAD to the
formerly-current commit).

These two commands will be used extensively in the upcoming changes to
'rebase -i -p'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rebase -i: introduce the 'merge' command

In edit scripts, 'merge [-c <message-commit>] <commit>...' will merge
the specified commits, possibly taking the commit message from another
commit.

This command will be used extensively in the upcoming changes to
'rebase -i -p'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rebase -i: allow a comment after 'merge'

Allow comments after a hash sign, i.e. lines in the edit script like
this one:

	merge -c abcdef cafebabe # comment

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
lib-rebase: handle more commands

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Teach rebase about preserving merges while in interactive mode

It has been quite a while since I tried my hand at this... But with Git
for Windows' fork needing to hold several topic branches, I felt the
need for something practical. Something like 'git rebase --interactive
--preserve-merges' that can handle fixup commits.

The major obstacle was the need to implement our own topological order.
Why? Because rev-list's topo-order is overly eager to continue with the
*last* parent after inspecting a merge commit, whereas we want to
continue with the *first* parent so that we have longer runs of "pick"
commands before merging, without having to jump around (if you're a
Badger, you may sing and dance at this point).

This is how we do it: we first make a list of tip commits (i.e.  commits
at the end of afore-mentioned pick & merge runs), in the order in which
we want to build the edit script.

For each tip, we then build the edit script in *reverse* order,
traversing from each commit to its first parent. Whenever we encounter a
parent commit that is already in the edit script, we remember to label
it and stop. Upon encountering a first parent commit that is not to be
rebased at all, we are done with that particular tip, too.

To support this mode, we added three new commands previously:

	label <name>: make a temporary ref for the now-current commit
	goto <name>: jump to a previously labeled temporary ref
	merge -c <commit> <parents>: perform a merge

Technically, we could have done all of these as "exec" lines, but they
would have looked horribly ugly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: rebase -p: Add an option to rebase all merged branches

When rebasing preserving merges, we exclude topic branches from being
rebased when they spawned off from the upstream earlier than the current
branch. The newly introduced option --rebase-merged-branches forces
those branches to be rebased onto the upstream commit, too.

Example:

	A - B - C
          \       \
            D - E - F
	      \
	        G

When rebasing F onto G, preserving merges, the result will look like
this *without* --rebase-merged-branches:

	A - B - C ----
	  \           \
	    D - G - E - F'

It will look like this *with* --rebase-merged-branches:

	A - D - G - B' - C'
	          \        \
	            E' ----- F''

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