True, the remote name is not necessarily going to be called "origin",
but that's a reasonable default.

This allows commit ranges to work even when the merge base branch hasn't
been created locally.

It's more convenient to have the "..." here because all of the
code-review commands use `get_merge_base`. Otherwise I'd end up having
to add it to most of the other commands.

But now, instead of only adding it to the default merge base, add it to
all merge bases, including the one set by `code-review-start`. This
makes all merge bases consistent, and means you don't have to include
the dots when setting a custom merge base.

This is inspired by a Git alias I have, `git ddiff`, that opens the Git
diff in the Delta diff viewer (https://github.com/dandavison/delta).
Delta ends up being much nicer than regular Git diff for code reviews
because it renders syntax highlighting.

I was inspired by Jake Zimmerman's blog post "Code Review from the
Command Line" (https://blog.jez.io/cli-code-review/) to add an
environment variable override for the merge base. This allows us to set
a different merge base for individual command executions.

This allows us to pass along arguments like `--ignore-all-space`.

Previously, the focused window in each tab was the Fugitive window that
contained the old version of the file. It's nicer to have the new
version focused by default, because that allows you to make changes to
the local source code.

I don't think this is the right approach, but since I added the "..." in
`code-review-changed-files` in 7659cf07f118fec4c1ba9677c82a7ef61511e797,
removing the "..." from here allows the difftool script to work when
using the default merge base.

Doesn't cover all the cases, but I think this should give us the correct
set of files when the merge base has been set via `code-review-start`.
Otherwise we might end up with a bunch of files that came from other
branches, not the one we're reviewing now.