rebase -i: Make option handling in pick_one more flexible

`pick_one` (`pick_one_preserving_merges` for merge commits respectively)
is the wrapper around `cherry-pick` in `rebase --interactive`. It takes
the hash of a commit and builds a `cherry-pick` command line that

 - respects the user-supplied merge options
 - disables complains for empty commits
 - tries to fast-forward the rebase head
 - suppresses output unless the user requested higher verbosity
 - rewrites merge commits to point to their rebased parents.

`pick_one` is not only used to implement its immediate correspondence
among the todo list commands `pick` but also `squash`, which amends the
previous commit rather than creating a new one. When `pick_one` is
called from `squash`, it receives a second argument `-n`. This tells
`pick_one` to apply the changes to the index without committing them.
Since the argument is almost directly passed to `cherry-pick`, we might
want to do the same with other `cherry-pick` options. Currently,
`pick_one` expects `-n` to be the first and only argument except for the
commit hash.

Prepare `pick_one` for additional `cherry-pick` options by allowing `-n`
to appear anywhere before the commit hash in the argument list. Loop
over the argument list and pop each handled item until the commit hash
is the only parameter left on the list. If an option is not supported,
ignore it and issue a warning on the console. Construct a new arguments
list `args` of recognized options that shall be passed to `cherry-pick`
on the command line.
rebase -i: Teach do_pick the option --edit

The todo list command `reword` replays a commit like `pick` but lets the
user also edit the commit's message. If one thinks of `pick` entries as
scheduled `cherry-pick` command lines, then `reword` becomes an alias
for the command line `cherry-pick --edit`. The porcelain
`rebase--interactive` defines a function `do_pick` for processing the
`pick` entries on todo lists. Teach `do_pick` to handle the option
`--edit` and reimplement `reword` in terms of `do_pick --edit`.

`do_pick` ought to act as a wrapper around `cherry-pick`. However, it
cannot just forward `--edit` to the `cherry-pick` command line it
assembles because the command is executed within a command substitution
for controlling the verbosity of `rebase--interactive`. Passing `--edit`
would either hang the terminal or clutter the substituted command output
with control sequences. Execute the old `reword` code instead when
`--edit` is specified.
rebase -i: pass diagnostic message to die in die_failed_squash

die_failed_squash is the error sequence for when a squash or fixup
command fails.

die_failed_squash issues a warning and calls die_with_patch with an
empty diagnostic message. Pass the issued diagnostic message to
die_with_patch instead of the empty string.

Prepare an easy-to-read patch set for implicitly making squash_msg the
commit message in die_with_patch when a squash or fixup is happening.
rebase -i: build diagnostic message for failed squash at call site

die_failed_squash is the error sequence for when a squash or fixup
command fails.

die_failed_squash passed a fixed diagnostic message to die_with_patch.
Take a second argument specifying the message contents instead to match
the signature of die_with_patch.

Prepare an easy-to-read patch set for implicitly making squash_msg the
commit message in die_with_patch when a squash or fixup is happening.
rebase -i: subsume die_failed_squash under die_with_patch

die_failed_squash is the error sequence for when a squash or fixup
command fails. Detect in die_with_patch whether we are in the middle of
a squash or fixup and insert squash_msg as commit message if that is the
case (copy the die_failed_squash code). Call die_with_patch instead of
die_failed_squash from the squash/fixup implementation so that the pick
error code looks the same both for ordinary picks and for
squashes/fixups. Remove die_failed_squash since it is no more used.

Complete the patch set.
rebase -i: Fail on empty and run hooks on root commits

Reasoning why this does not change behaviour missing.
rebase -i: Create only a single commit for rewritten picks

The `do_pick` arguments determine whether the picked commit will be
rewritten or not. If the commit gets rewritten, because the user
requested to edit the commit message for instance, let `pick_one` merely
apply the changes introduced by the commit and do not commit the
resulting tree yet. If the commit will be replayed as is, leave it to
`pick_one` to recreate the commit (possibly by fast-forwarding the
head).

In the `--edit` case, do not `exit_with_patch` but set `rewrite` to pick
the changes with `-n`. If the pick conflicts, no commit is created which
we would have to amend when continuing. Make the commit error message
less specific to `--edit` because `do_pick` will support additional
rewrite options.

In case `rebase--interactive` is used to rebase the complete history
onto some head, `rebase` creates a sentinel commit that requires special
treatment in `do_pick`. Do not finalize the pick here either because its
commit message can be altered like for any other pick. Since the
orphaned root commit gets a parent it is always rewritten, safely use
the rewrite infrastructure to create the pick commit.
rebase -i: Do not die in do_pick

Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect but
exiting the sub-shell with a failure exit status. Indicate an error in
`do_pick` using return statements and properly kill the script at the
call sites. Remove unused commit message title argument from `do_pick`.
rebase -i: Prepare for squash in terms of do_pick --amend

Rewrite `squash` and `fixup` handling in `do_next` using the atomic
sequence

    pick_one
    commit

in order to test the correctness of a single `do_squash` or parametrized
`do_pick` and make the subsequent patch reimplementing `squash` in terms
of such a single function more readable.

Might be squashed into the subsequent commit.
rebase -i: Teach do_pick the options --amend and --file

The todo list command `squash` and its close relative `fixup` replay the
changes of a commit like `pick` but does not recreate the commit.
Instead it replaces the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without committing and using `commit` to amend the
previous commit:

The todo list

    pick   a Some changes
    squash b Some more changes

gets translated into the sequence of git commands

    git cherry-pick a
    git cherry-pick -n b
    git commit --amend

and if `cherry-pick` supported `--amend` this would look even more like
the todo list it is based on

    git cherry-pick a
    git cherry-pick --amend b.

Since `do_pick` takes care of `pick` entries and the above suggests
`squash` as an alias for `pick --amend`, teach `do_pick` to handle the
option `--amend` and reimplement `squash` in terms of `do_pick --amend`.

Discussion of implementation missing.