rebase -i: Explicitly distinguish replay commands and exec tasks

There are two kinds of to-do list commands available. One kind replays a
commit (`pick`, `reword`, `edit`, `squash` and `fixup` that is) and the
other executes a shell command (`exec`). We will call the first kind
replay commands.

The two kinds of tasks are scheduled using different line formats.
Replay commands expect a commit hash argument following the command name
and exec concatenates all arguments to assemble a command line.

Adhere to the distinction of formats by not trying to parse the `sha1`
field unless we are dealing with a replay command. Move the replay
command handling code to a new function `do_cmd` which assumes that the
first argument to be a commit hash and make no more such assumptions in
`do_next`.
rebase -i: Parse to-do list command line options

Read in to-do list lines as

    command args

instead of

    command sha1 rest

so that a to-do list command lines can contain additional arguments
apart from the commit hash and the log message title, which become the
non-options in `args`. Loop over `args`, put all options (an argument
beginning with a dash) in `opts`, stop the loop on the first non-option
and assign it to `sha1`. The loop does not know the options it parses so
that option arguments are not supported at the moment. Neither are
options that contain spaces because the shell expansion of `args`
interprets white space characters as argument separator, that is a
command line like

    pick --author "A U Thor" fa1afe1 Some change

is parsed as the pick command

    pick --author

and the commit hash

    "A

which obviously results in a unknown revision error. For the sake of
completeness, in the example above the message title variable `rest` is
assigned the string 'U Thor" fa1afe1 Some change' (without the single
quotes).

Print an error message for unknown or unsupported command line options,
which means an error for all specified options at the moment. Cleanly
break the `do_next` loop by assigning the special value 'unknown' to to
the local variable `command`, which triggers the unknown command case in
`do_next`.

The to-do list is parsed when the commit hashes are translated between
long and short format before and after the to-do list is edited. Apply
the same procedure as in `do_next` with the exception that we only care
about where the options stop and the commit hash begins. Do not reject
any options when transforming the commit hashes.
rebase -i: Enable options `--signoff`, `--reset-author` for pick, reword

pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task which
is not completed until the last squash or fixup is processed.

Lift the general unknown option blockade for the pick and reword
commands. If `do_next` comes across one of the options `--signoff` and
`--reset-author` while parsing a to-do entry and the scheduled command
is either `pick` or `reword`, relay the option to `do_pick`.

The `do_pick` options `--gpg-sign` and `--file` are not yet supported
because `do_next` cannot handle option arguments and options with spaces
at the moment. It is true that edit is one of the atomic commands but it
displays hash information when the rebase is stopped and some options
rewrite the picked commit which alters that information. squash and
fixup still do not accept user options as the interplay of
`--reset-author` and the author script are yet to be determined.
rebase -i: Handle rebase option --gpg-sign in do_pick

If `--gpg-sign` is passed to git-rebase, all replayed commits are
GPG-signed. In interactive mode, pretend `--gpg-sign` is passed to every
to-do list command by relaying `gpg_sign_opt` to `do_pick` in `do_next`.
`gpg_sign_opt` is either of the format `-S` or `-S<keyid>` which are
both supported by `do_pick`.