magit-file-log: use magit-refresh-log-buffer

In `magit-file-log' use the generic `magit-refresh-log-buffer'
(and pass it `magit-custom-options'), instead of the inferior
`magit-refresh-file-log-buffer'.  The latter was an incomplete
reimplementation of the former "specialized" for "file logs".
In the previous commit we taught the latter the FILE argument;
nothing else was necessary to make it suitable for "file logs".
magit-file-log: with a prefix argument pass --graph to `git log'

Even before this commit showing the graph was possible but only when it
was invoked from the logging popup.  Now this is also possible when the
command is directly invoked.
Merge branch 'file-log-v4'

Conflicts:
	magit.el
Merge branch 'praet/process-keep-hist'

Conflicts:
	magit.el
magit-wash-branches-between-point-and-marker: simplify
magit-wash-remote-branches-group: simplify
magit-wash-branches: lose whitespace
Merge branch 'pr/cleanup-branch-manager'
merge file magit-cherry.el into magit.el

Define the cherry functionality previously defined in the separate file
`magit-cherry.el' in `magit.el'.  The complexity and code size are both
to low to justify having a separate file.  This will also make it easier
to use "cherry" in other parts of Magit.
use existing abstractions to implement cherry

Remove `magit--refresh-cherry-buffer' which reimplemented functionality
already available elsewhere.  `git cherry' can be seen as a `git log'
with less options but an additional twist.  Teach `magit-format-log-line'
and `magit-parse-log-line' the new `cherry' style.  Define the format in
`magit-log-cherry-re'.

Define a washer `magit-insert-cherry-commits' that works like other "log"
washers in that in only washes the list of commits.  Add inserters that
insert header line sections, and add `magit-cherry-insert-sections-hook'
to allow reordering.  This can also be used remove the help text, we
display by default because the old implementation did it too.

Always make the help text less verbose.  Don't add spaces around the
cherry type indicator (+ or -), because that only looked good if the
faces used to display them did set the background color.

Note that "Head" means something else in the cherry buffer than the
status buffer.  This ambiguity is inherited from Git, but we might be
able to do something about it later.  The "Upstream" header still has
to be improved.  I had intended to use `magit-format-tracked-line' for
that purpose but that isn't able to deal with the ambiguity of user
input.  And since that is an issue that also effects other areas I'll
leave it at that for now, and don't attempt to prettify the upstream.
magit-wash-log: when washing cherry output, reverse it first

When `magit-wash-log' washes `git cherry' output it now starts washing
by reversing the git command's output.  This makes the order of cherries
consistent with the order of unpushed/unpulled commits as displayed in
the status buffer.

The order of commits in such "preview" commit lists should probably be
customizable; for now we just make it consistent.
add magit-insert-{unpulled,unpushed}-cherries

Add `magit-insert-{unpulled,unpushed}-cherries', intended for use in the
status buffer.  They are more informative (but much slower) variants of
`magit-insert-{unpulled,unpushed}-commits'.  Because of the speed issue
don't use them by default and don't even advertise them.

Speedup will come later (most likely by caching cherries in elisp,
instead of using `git cherry').
magit-cherry: change argument order

Switch the position of `magit-cherry's UPSTREAM and HEAD arguments.
In interactive use it makes more sense to read the HEAD first, because
that allows defaulting to the tracked branch when later reading UPSTREAM.
Do not just change the order of reading, actually change the order of the
arguments so that interactive and non-interactive use is consistent.

However do not change the order accordingly for function
`magit-refresh-cherry-buffer' and in the value of variable
`magit-refresh-args'.  Here we should instead be consistent with `git
cherry'.  Also changing the order here would complicate matters.

Don't refuse to run when HEAD (the actual git HEAD, not the argument) is
detached.  It is possible to select any rev not just refs as the cherry
head.  And why refuse to run with a detached HEAD if the user is
actually about to select some ref?
add faces magit-cherry-{equivalent,unmatched}

Add the faces `magit-cherry-equivalent' and `magit-cherry-unmatched',
defining them from scratch.  Do not inherit from `magit-diff-{add,del}.
These faces are added exactly because they should not both look the same
as the diff face the corresponds to the same symbol `+' or `-'.  The +┌-
distinction for diffs is distinct from the +┌- distinction for cherries.

Use boring foreground colors that are likely to work with both light and
dark themes.  Do not set the background because that would be overridden
by section highlighting.
Merge branch 'pr/cherry'
add preliminary implementation of magit-format-ref-label

Add a preliminary implementation of function `magit-format-ref-label'
which returns a list whose only element is a propertized ref label; or
nil.  It should actually return just the propertized label; always.

This function is a wrapper around `magit-ref-get-label-color' and
lessens the pain of using that somewhat.  However it also inherits some
of the limitations, including but not limited to, the above.  The
biggest problem is does both filtering and formatting.  Actually fixing
this and other issues would require some refactoring.  I am adding this
kludge instead so that I can land some other things first, that have
been on the waiting list for to long already.
fix typo in comment
reimplement wazzup from scratch

The old implementation was problematic because it did not use the
existing abstractions used elsewhere and because was very slow (521).
Because of the former issue it was needlessly complicated, while also
lacking features.  And in order to address the latter two different ways
of limiting what branches are displayed were added, again making it more
complex than it needs to be.

Additionally one of these filter mechanisms required that the user
individually marked branches he did not want to be shown.  Because doing
so results in a refresh of the complete buffer this effectively meant
that he, in order to eventually get a speedup, had to repeat the action
which he wants to speedup - several times, adding insult to injury.

This implementation takes a different approach.  Like this is also done
for diff hunks but until now nowhere else, it does not merely hide the
body of collapsed sections, it does not even calculate the commits until
they are actually being displayed.

Unfortunately the section framework has several shortcomings which
result in a lot of complexity in `magit-insert-wazzup-commits'.  In
theory this function could be almost as simple as, lets say,
`magit-insert-unpulled-commits', but as of now it consists of a
collection of kludges.  Fixing the section api to make this unnecessary
is a difficult task and requires changes throughout Magit.  So that will
have to wait until another day.

Because wazzup is much faster now this does not add a new and better
exclude mechanism.  Instead the old mechanisms are dropped without a
replacement.  This can still problematic when a user expands all
sections (e.g. using M-2) but he doing so does not make much sense -
especially not when there are many branches.
magit-wazzup: with prefix argument allow selecting another rev
magit-insert-wazzup-commits: use cherry instead of regular log

Use `git cherry' instead of `git log'.