assert unrecord-window-buffer is defined before using it
magit-display-process: use pop-to-buffer instead of display-buffer

Prior to commit e26c9c7 `magit-display-process' used `display-buffer'
and `magit-run*' used `pop-to-buffer' for timed display of the same
buffer.  The latter code was merged into `magit-display-process', which
resulted in `display-buffer' always being used.

This commit changes it to always use `pop-to-buffer'.

Fixes #987.
add new functions magit-{region,section}-siblings
magit-{,un}stage: allow un-/staging region of files

Note that this will un-/stage the file on the current line even when
point is at its very beginning.  So it behaves more like e.g. dired
than the un-/staging of a region within a hunk.  Also both mark and
point have to be on a file *heading*.
Merge branch 'pr/stage-region'
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