add option magit-item-highlight-face

Add option `magit-item-highlight-face' to once and for all satisfy all
users, hopefully.  Actually, that is not possible; so what this actually
does, is to allow users to customize the appearance of the highlighting
without imposing any limitations.

The previous attempt implemented in at least the commits 66a0644,
d14a3f9 (with discussion), and d14a3f9; and discussed in the issues #743
and #865 failed.  They fixed it for some users and in turn broke it for
others.  The primary goal of this change is to help users help
themselves, in case they don't like the defaults.

The new option `magit-item-highlight-face' is necessary because face
inheritance has serious limitations when a theme is used.  It is not
possible for the user to "unset" a face attribute that was previously
set by the theme.  All that is possible is to *change* it to some other
value.  "Make unset" isn't available as a value.

This option also makes it possible to automatically set the default of
option `magit-diff-use-overlays' to nil in *one particular* case: when
`magit-item-highlight-face's value is `bold'.  (We previously tried
something similar, but that failed because of another limitation of
faces, :set-after only works for options, not faces).

This commit also changes the appearance of some faces, which might
disappoint some users.  There simply isn't anything we can do to make
this look good out of the box for everyone.  Unfortunately for some
people that will mean that we have switched from a default that worked
for them to one that doesn't.  I hope that, when pointed to this
message, it becomes obvious, that it isn't as easy as one might have
thought, and that we had to make compromises.

The following considerations went into choosing the colors used for
various themes:

* Being at least _usable_ in (hopefully) all cases is more important
  than being _pretty_ in most cases.  We are not in the business of
  designing consistent color themes.

* Inherit from default faces, hoping that doing so, results in
  consistent, semantically sound, and possibly even pretty colors.
  If that is not so that is the mistake of the theme authors.

* The colors red and green, in all its variations, have to be avoided
  because those colors are also used to indicate removed and added lines
  in diffs.

* Therefore inherit from default faces that, in the default theme (both
  the dark and light variant), don't use such colors.  Of course some
  third-party theme might have changed these faces to use red or green;
  we simply cannot do anything about that.

* The faces we inherit from also have to be semantically close to
  "highlight".  Which gives us `highlight', `region', and
  `secondary-selection'.

* `region' cannot be used because it is also used for... the region,
  which is useful when staging just a portion of a hunk, precisely *the
  region*.

* `highlight' cannot be used because it is green.

* `secondary-selection' and only that remains.  Use it.  It might not
  be pretty even when using the default theme, but if it is good enough
  for the designers of the default theme then it is good enough for us.
  Besides we don't have another option.

So make `magit-item-highlight' inherit from `secondary-selection' and
make `magit-item-mark' (which previously inherited from the former)
inherit from `highlight'.  It's okay for `magit-item-mark' to be green;
only commits can be marked, and commits don't appear next to added (or
removed, or unmodified) lines.
Merge branch 'pr/bold-highlight'
Fix option of git ls-files in magit-revert-buffer
Merge pull request #995 from shigi/fix-ls-files-option

Fix option of git ls-files in magit-revert-buffer
remove function magit-log-cutoff-length-arg
remove constant magit-log-format
magit-log-{one,long}line-re: re-indent
magit-log-{one,long}line-re: put "refs" pattern on single line

This results in a long line, which is okay because that will be
fixed in a subsequent commit.
magit-log-oneline-re: improve matching that extra space
magit-log-oneline-re: merge the optional shy groups

In `magit-log-oneline-re' merge the optional shy groups.  The parts they
match only appear in combination (on an actual log line) or none of them
do (on a graph-only line).
magit-log-{one,long}line-re: improve graph matching
magit-log-longline-re: make definition more compact

As of now it probably looks like this is *too* compact - but
it will get better.
magit-log-longline-re: deal with three kinds of lines

There are up to three kinds of "log lines" that the `magit-log-{*}-re'
functions have to match.

* "actual log"   appearing in   long, oneline, others
* "graph-only"   appearing in   long, oneline
* "details"      appearing in   long

That might not be such a good idea - it certainly complicates writing
the regexps.  For now just make the regexps fully aware of that fact.

For "long log" that means that a line either contains a hash (and
possibly refs) **or** it has "something else".  For other log types that
would be the "message", but for "long log" that does not make much sense
- it is better to think of it as "the rest" after the (optional) graph.

In order not to complicate things we keep pretending this is "the
message" but we adjust the regexp to reflect the distinction.  By doing
so we prepare it for future changes.
remove magit-{ref-nonslash-re,ref-nonchars,refname-re}

Remove the constant regexp variables `magit-ref-nonslash-re',
`magit-ref-nonchars', and `magit-refname-re'.  They were only used as
part of the constant values of the variables `magit-log-oneline-re' and
`magit-log-long-re' regexp constants.

The substrings these partial regexps were matched against either did not
exist at all, or they were guaranteed to contain only refs.  So there
really is no good reason to assert that the substrings consists of refs;
we know they always do.
reverse order in which log-washing functions are defined
magit-parse-log-line: stop misleading the reader

`magit-wash-log-line' is called repeatedly by `magit-wash-sequence'
until the latter returns nil or the end of the buffer or narrowed part
is reached.

`magit-wash-log-line' never returns nil, the explicit `t' at its end
makes sure of that.  And even without that it would never return nil.

So the reason `magit-wash-sequence' ever stops calling the washer is
that the end of the buffer or narrowed part is reached.  In practice
that means that all callers of `magit-wash-log' have to narrow to the
relevant portion before initiating the washing.

In other words `magit-parse-log-line' only ever gets to see lines that
are actual log lines.  It is therefor misleading that its body is
wrapped in a `when' form.
magit-wash-log-line: no need to assert line is non-nil

`magit-parse-log-line' always returns a `magit-log-line' struct - never
nil.  Therefor in `magit-wash-log-line' (its only caller) do not assert
this is indeed so - we know it is.  This change is about not misleading
the reader.
magit-wash-log-line: absorb magit-{parse,format}-log-line

Merge `magit-format-log-line' and `magit-parse-log-line' into
`magit-wash-log-line'.  `parse' was only used by `format', which in turn
was only used by `wash'.  Splitting the various subtasks into separate
functions did only complicate things.

In the process remove the `magit-log-line' struct which was only ever
used to pass an ordered collection of values from `parse' to `format'.
That was quite silly in itself, a simple would have been equally
powerful and much more compact.  This is just the tip of the iceberg.
magit-wash-log-line: rename internal variable from sha1 to hash
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'.