fake_editor: leave standard output unchanged

The helper function `set_fake_editor` installs a script as
`GIT_EDITOR` that applies pre-defined editing rules to the files it
is called with, which is a quite powerful tool when writing test
cases for git-rebase--interactive. To aid in debugging the changes it
makes, the installed script dumps the file contents to stdout before
and after editing. That interferes with the output from
git-rebase--interactive, however, and the debug information has to be
removed from stdout in a error-prone way. Print the editor contents
on stderr instead.

When a test case wants to analyse stderr, we need to come up with a
different solution. The less convenient possibility that always
remains is to store the debug output in a file in the "trash"
directory or even keeping copies of the edited files before and after
editing.
squash! rebase -i: hide interactive command messages in verbose mode

rebase -i: hide interactive command messages in verbose mode

git-rebase--interactive prints summary messages of the commits it
creates in the final history only if the `--verbose` option is
specified by the user and suppresses them otherwise. This behaviour
is implemented by wrapping git-commit calls in a shell function named
`output` which redirects stderr to stdout, captures stdout in a shell
variable and ignores its contents unless the command exits with an
error status.

The command lines used to implement the to-do list commands `reword`
and `squash` print diagnostic messages even in non-verbose mode. The
reason for this inconsistency is that both commands launch the log
message editor `GIT_EDITOR` which usually requires a working terminal
attached to stdin. Wrapping the `reword` and `squash` command lines
in `output` would seemingly freeze the terminal (see commit 7725cb5,
"rebase -i: fix reword when using a terminal editor"). Temporarily
redirect the `GIT_EDITOR` output to a third file descriptor in order
to ship it around the capture stream. Wrap the remaining git-commit
command lines in the new `output`. At the moment, it is still no
alternative to pass the `--quiet` option in non-verbose mode because
git-merge-recursive for instance prints some messages regardless of
the verbosity level.

In order to temporarily redirect the editor output, the new
definition of `output` creates a wrapper script in the state
directory to be used as `GIT_EDITOR`. Make sure the state directory
exists before `output` is called for the first time.
squash! rebase -i: root commits are replayed with an unnecessary option

rebase -i: do not use -C when --no-edit is sufficient

The command line used to recreate root commits uses `-C` to suppress
the log message editor. This is unnecessarily confusing, though,
because that suppression is a secondary effect of the option. The
main purpose of `-C` is to pull the metadata from another commit, but
here we know that this is a no-op, since we are amending a commit
just created from the same data.

At the time `-C` was introduced, git-commit did not yet have a
documented `--no-edit`, and this was a reasonable way to get the
desired behavior. Switch it to use `--no-edit` to make the intended
effect more obvious.
squash! rebase -i: failed reword prints redundant error message

rebase -i: discard redundant message when rewording fails

The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.

    1. The git-commit output, which contains all the output from hook
       scripts.
    2. A rebase diagnosis saying at which task on the to-do list it
       got stuck.
    3. Generic presumptions about what could have triggered the
       error.

The third message contains redundant information and does not add any
enlightenment either, which makes the output unnecessarily longish
and different from the other commands' output. For instance, this is
what the output looks like if the log message is empty (contains
duplicate Signed-off-by lines).

    (1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
    (2.) Could not amend commit after successfully picking fa1afe1... Some change
    (3.) This is most likely due to an empty commit message, or the pre-commit hook
         failed. If the pre-commit hook failed, you may need to resolve the issue before
         you are able to reword the commit.

Discard the third message.

It is true that a failed hook script might not output any diagnosis
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
hooks require improvement.
squash! rebase -i: squash skips commit-msg hook

rebase -i: verify squash messages using commit-msg

Using the to-do list command `squash` the user can specify two or
more commits and git-rebase creates one commit that introduces all
their changes combined. The authorship for the created commit is
taken from the first commit specified and the user can edit the log
message. There is a variant of `squash` available named `fixup` which
also takes the first log message without asking for user input.

While it is reasonable to not verify replayed changes twice or
rejecting some other author's changes in her name, it is insufficient
to not verify the user input used as log message in the case of
`squash`. Specify the git-commit option `--no-pre-commit` instead of
`--no-verify` when committing the squash result, but not before, to
let the commit-msg hook verify the final squash message. For the same
reasons the pre-commit hook is disabled in all replay modes, the
commit-msg hook is disabled in `fixup` mode.

Add tests. In addition to the existing test checking that the
pre-commit hook is disabled when simply picking a commit, provide a
test checking that the commit-msg hook is disabled as well.