rebase -i: Make option handling in pick_one more flexible

`pick_one` and `pick_one_preserving_merges` are wrappers 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 complaints about 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 used to implement not only `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 `extra_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 root commits and run hooks

When `rebase--interactive` is executed with `--root` but no `--onto` is
specified, `rebase` creates a sentinel commit which is replaced with the
root commit in three steps. Firstly, the authorship of the root commit
is forced on the sentinel. Secondly, the changes introduced by the root
commit are applied but not committed. If this step fails due to
conflicts, all commit information is in place and the user can safely
run `git-commit` after resolving the conflicts. Thirdly, the changes are
squashed into the sentinel commit which already carries the authorship
of the cherry-picked root commit. The command line used to commit the
changes in the third step specifies effectless or erroneous arguments.
Remove those.

 - `--allow-empty`: Whether the resulting commit is empty or not depends
   on the applied changes. If the root commit is empty, it is either
   skipped when the to-do list is put together or applied using
   `--allow-empty`.

 - `--allow-empty-message`: Whether the resulting commit message is
   empty or not depends on the commit message of <commit>. If the root's
   commit message is empty, the rebase fails like for any other commit
   that is on the todo-list and has an empty commit message. Fix the bug
   that `rebase--interactive` does not fail when the initial commit has
   an empty commit message and `--root` is specified.

 - `-n` ???. Fix the bug that `rebase--interactive` does not run the
   pre-commit and commit-msg hooks when the root is recreated using
   `--root`.

 - `-C` has no effect since the amended commit, which is the sentinel
   commit, already carries the authorship of the cherry-picked commit.

After all, if step two fails, `rebase --continue` won't include these
flags either.
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 temporary parent it is always rewritten,
safely use the rewrite infrastructure to create the pick commit. Fix the
bug that failed root commit application leaves the sentinel commit
behind.
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. Moreover, if `do_pick`
was called while a squash or fixup is happening, `die_with_patch` would
discard `$squash_msg` as commit message. 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.