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.