explicitly number submatches in log-line regexps

In `magit-log-{oneline,longline,unique,reflog}-re' number the submatches
explicitly.  The subexpressions/parts common to more styles get a lower
number than those only relevant to one or two styles.

Then take the dance bear out of `magit-wash-log-line'.
add macro magit-bind-match-strings

Why can't something like `bind-match-strings' just be part of Emacs?
Even just `match-strings' (plural) would be great.  Hell, even making
`match-limit' available in lisp would be of some help.  Instead we all
have to bang on `match-data' or manually construct `let's VARLIST by
hand.  Not anymore, at least not in Magit.
magit-log-{oneline,longline,cherry,reflog}-re: cosmetics
magit-wash-log-line: for longline, put hash behind graph

Function `magit-wash-log-line' used to put the commit hash before the
graph for all log styles.  In case of the "long" log this just wasted
space.  So now the graph comes first for that style.
magit-wash-log-line: for longline, show full hash, if there is room

When washing a "long" log `magit-wash-log-line' now inserts the full
hash, iff there is enough room, that is when there are no refs that
point to the commit.
magit-wash-log-line: make complete entry part of section

Function `magit-wash-log-line' turns each line that actually represents
a log entry into a section.  (It does not do so for graph-only lines).

When washing "oneline" logs that works find, but a "long" log entry
actually consists of all lines up to the next entry.  This commit
teaches `magit-wash-log-line' how to make the complete entry part of
the section.
Merge branch 'pr/wash-log-wash'
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'
don't store face section in a diffstat struct a third time

It is a common issue that the type of a section is stored in the section
struct twice, in slot TITLE and TYPE.  Sometimes one is a string and the
other a symbol, but there is little consistency which of the two is what.
And then these slots are also used as magic switches for only slightly
related functionality.  That's all pretty bad in itself, but...

For diffstat sections this was taken a step further.  The symbol
`diffstat' was additionally also stored as the car of the INFO slot.
And there even was a dedicated function to retrieve that information,
but it was never used.  Remove that function and don't cons `diffstat'
onto INFO, its "not necessary".