internal/cmd: git_wrapper: wrap difftool and mergetool

[marcuslannister]

Closes #83.

git diff 1 expands the shortcut, but git difftool 1 fails with
fatal: ambiguous argument '1'. The two commands take the same pathspec
arguments, so the difference is surprising. difftool simply is not in the
wrapper's dispatch list.

This adds difftool and mergetool to the --relative branch.

mergetool is included because scmpuff numbers conflicted files during a
merge — precisely when picking one by number is most useful. That is the
request in #83, where the suggested workaround was to use $e1 directly.

Neither command has the ambiguity that makes stash a special case in #160:
for stash pop 1 a number is a stash index, but difftool and mergetool
only ever take paths.

Tests

Two testscripts, covering bash, zsh and fish:

• command-shell-wrapper-difftool-by-number.txtar — uses --extcmd=echo so
  no real diff tool is needed, and asserts the tool receives the relative
  worktree path.
• command-shell-wrapper-mergetool-by-number.txtar — builds a real merge
  conflict and resolves it with a stub tool, so nothing interactive runs.

Note on zsh -f

The new scripts invoke zsh with -f, which the existing wrapper tests do not.

zsh reads /etc/zshenv for every shell, including non-interactive ones. On
some systems that file prepends profile directories to PATH — nix-darwin
does this, and I hit it locally. The effect is that the zsh leg silently runs
an installed scmpuff instead of the binary under test.

The current wrapper tests cannot detect this, because every subcommand they
cover (add, reset, restore) exists in both the installed and the
under-test version, so the results agree either way. A test for a newly added
subcommand is the first one that can catch the substitution — which is how I
found it. -f makes the zsh leg hermetic.

Happy to drop the -f if you would rather keep the scripts uniform, or to
apply it to the existing scripts in a separate change.

[mroth]

@marcuslannister this looks great! I wasn't aware of the -f flag, that makes sense to make the integration tests more portable. A follow up PR to add it to the other scripts sounds great as well.