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: 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.