Elijah Newren authored Dec 11, 2018 and Junio C Hamano committed Jan 07, 2019

As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.

Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options.  As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore.  Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.

This results in a few deliberate but small user-visible changes:
  * The progress output is modified (see t3406 and t3420 for examples)
  * A few known test failures are now fixed (see t3421)
  * bash-prompt during a rebase --merge is now REBASE-i instead of
    REBASE-m.  Reason: The prompt is a reflection of the backend in use;
    this allows users to report an issue to the git mailing list with
    the appropriate backend information, and allows advanced users to
    know where to search for relevant control files.  (see t9903)

testcase modification notes:
  t3406: --interactive and --merge had slightly different progress output
         while running; adjust a test to match the new expectation
  t3420: these test precise output while running, but rebase--am,
         rebase--merge, and rebase--interactive all were built on very
         different commands (am, merge-recursive, cherry-pick), so the
         tests expected different output for each type.  Now we expect
         --merge and --interactive to have the same output.
  t3421: --interactive fixes some bugs in --merge!  Wahoo!
  t9903: --merge uses the interactive backend so the prompt expected is
         now REBASE-i.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>