magit-rev{,-range}-{to-git,describe}: don't raise an error if REV is nil

The helpers `magit-rev-to-git', `magit-rev-range-to-git',
`magit-rev-describe', and `magit-rev-range-describe' should not check
whether the REV or RANGE argument passed to them is nil and in that case
raise an error.  The REV or RANGE being nil is an error that should be
caught way before it reaches this function.  In fact I believe that this
error handling was added here because in the past `magit-read-rev' and
`magit-read-rev-range' did not raise an error on empty input.  The
latter is fixed now, so this kludge can be removed.
instantly convert "." to the value of magit-marked-commit

Until this commit `magit-rev-to-git' converted the string "." to the
value of `magit-marked-commit', and `magit-rev-describe' replaced it
with the string "mark".

There is only one place where such a "." string to represent
`magit-marked-commit' could come from: the user providing that string
when asked for a revision by `magit-read-rev'.  So instead of passing
that ominous value through many functions that have no understanding of
its meaning, instanly convert it to the value of `magit-marked-commit'.

The only (mis-)feature this loses is that `magit-rev-describe' now
inserts the actual rev or ref `magit-marked-commit' points to instead
of the, not so helpful, "mark" string.
remove function magit-rev-to-git

Remove function `magit-rev-to-git', because after the last two commits
it no longer did anything but return its only argument unchanged, just
like `identity'.
remove function magit-rev-describe

Remove function `magit-rev-describe' as it no longer does anything but
wrap around `magit-name-rev'.  It neither manipulated the input nor the
output.
magit-refresh-log-buffer: don't treat --all-match like --all

`--all' means: Pretend as if all the refs in refs/ are listed on the
command line as <commit>.

`--all-grep' means: Limit the commits output to ones that match all
given --grep, instead of ones that match at least one.

One has nothing to do with the other.  In the latter case the commits
are still limited by some revision argument.
magit-refresh-log-buffer: stop using magit-rev-range-describe

In `magit-refresh-log-buffer' stop using `magit-rev-range-describe'.
Currently revision ranges are passed around as cons cells, which is
wrong for several reasons.  Because this commit is only one of the
steps required to undo that design error, it does contain a kludge.

This changes the buffer headings for ranged/other logs from:

  Commits in RANDOM-NAME-FOR-REVISION
  Commits from RANDOM-NAME-FOR-REVISION-A to RANDOM-NAME-FOR-REVISION-B

to

  Commits in REVISION-AS-GIVEN-BY-USER
  Commits in REVISION-A-AS-GIVEN-BY-USER..REVISION-B-AS-GIVEN-BY-USER

That's one small step backward for prettiness, one giant leap forward
for correctness.  Currently Magit cannot tell A..B and A...B apart,
this, and other changes, will eventually make fixing this possible.
And displaying SOME-REF-MATCHING-REV isn't helpful when the user
explicitly inserted something like "HEAD~5".
magit-refresh-diff-buffer: stop using magit-rev-range-describe

In `magit-refresh-log-buffer' stop using `magit-rev-range-describe', by
replacing several design errors with temporary kludges.  The kludges are
necessary because the errors are not locally contained and over time
have propagated throughout `magit.el'.  One of the mistakes this commit
tries to address is that revision ranges are passed around as cons
cells, which is wrong for several reasons.

This changes the buffer headings for relative-to-worktree/range/stash
diffs from:

  Changes in RANDOM-NAME-FOR-REVISION
  Changes from RANDOM-NAME-FOR-REVISION-A to RANDOM-NAME-FOR-REVISION-B
  Changes from RANDOM-NAME-FOR-stash@{N}^2^ to stash@{N}

to

  Changes in REVISION-AS-GIVEN-BY-USER
  Changes in REVISION-A-AS-GIVEN-BY-USER..REVISION-B-AS-GIVEN-BY-USER
  Changes in stash@{N}^2^..stash@{N}

That's one small step backward for prettiness, one giant leap forward
for correctness.  Currently Magit cannot tell A..B and A...B apart,
this, and other changes, will eventually make fixing this possible.
And displaying SOME-REF-MATCHING-REV isn't helpful when the user
explicitly inserted something like "HEAD~5".  In case of stash diffs
the old pretty heading was just wrong and the new heading is very
ugly - ugly is better.
remove function magit-rev-range-describe

Remove the function `magit-rev-range-describe', as the last two commits
have made it unnecessary.  This sucker probably was the starting point
of *a lot* of accidental complexity.  Finally it is gone.
magit-refresh-log-buffer: use RANGE as argument to Git

`magit-refresh-log-buffer' now uses its own RANGE argument as an
argument to git.  `magit-log' and `magit-log-long' no longer cons
the range onto the `magit-refresh-log-buffer's ARGS argument.
remove function magit-rev-range-to-git

Remove the function `magit-rev-range-to-git'.  Since that was the last
member of the section titled "worrisome to-git converters", that heading
can be removed too.  The previous commits have demonstrated that these
functions were not necessary (nothing of value (as in: not harmful) was
actually lost by removing them) and their existence did not actually
reduce code size (they, combined with their use, increased it by 60
lines).
remove variable magit-current-range

Remove the variable `magit-current-range' which is only ever set but
whose value is never actually used.  Besides its value could also be
retrieved from `magit-refresh-args'.
Merge branch 'pr/tumor'