magit-uninteresting-refs: improve regexps

* Anchor all regexps.
* We are not interested in submatches.
* Put each regexp on its own line; this list will grow.
magit-uninteresting-refs: always ignore topgit refs

Add the regexps that cause the topgit "top-base" refs to be ignored to
the definition of `magit-interesting-refs' instead of adding them only
when `magit-topgit-mode' is turned on.

I guess it could happen that someone does not use topgit and uses
"refs/top-bases" and "refs/remotes/REMOTE/top-bases" for something else,
but I think it that is rather unlikely.  If it does happen, that user
can just remove the respective regexps from the variable - which by the
way will get easier once it is a customizable option.
magit-log-{remote-color-hook,get-remote-color}: remove

Now that `magit-wash-log-line' filters refs before colorizing them,
we no longer need to abuse _colorizing_ to also perform _filtering_.

So the `magit-log-remote-color-hook' variable as well as the wrapper
function `magit-log-get-remote-color' can be finished off.
magit-list-interesting-refs: allow filtering list of refs
magit-list-interesting-refs: never trim refs

Always return  ((NAME . FULL-REF)...)
instead of     ((NAME . FULL-OR-ABBREVIATED-REF)...).

Previously the cdr in all but one case was the full ref.  The exception
was the most common case when REF began with "refs/heads/", in which
case that part was removed from the ref.

The old behavior was not helpful.  Sure, the (now) only caller needs the
refs to be abbreviated when they are branches, but that isn't an inherent
requirement - on the contrary that caller also has issues.
magit-format-ref: remove incorrect doc-string

The doc-string describes what this function should be doing, not what it
does.  We will fix that step by step, but since the last step will be
the removal of this function there is no point in repeatably changing
the doc-string.
magit-format-ref: expect the REF argument to be non-nil
magit-format-ref: do not also filter

Previously `magit-format-ref' did return nil for refs other than
"refs/{head,remote,tag}/...".  Stop doing that, formatting should
not be overloaded to also filter.

As a result some refs are now displayed in logs, that previously were
not.  For some users this will be a regression, for others it will be a
welcome change.

Once `magit-uninteresting-refs' is an option, it will be easy for users
in the first group to, "fix" this change.
magit-wash-log-line: don't filter tag refs

In `magit-wash-log-line' do not attempt to remove tags from the list of
refs to be displayed.  Previously this was done by filtering out "refs"
that begin with "tag:", which was wrong for two reasons: (a) there are
no such refs, and (b) we would not want to filter out tags, seeing them
in logs (and elsewhere) is kinda useful.
magit-wash-log-line: filter refs before colorizing them
magit-log-head-label-wip: define in magit.el

This prepares for the next commit.  After that the face might be used
even when `magit-wip.el' isn't loaded.
magit-wip-mode: remove mode

Remove `magit-wip-mode' which was used to give "refs/wip/BRANCH" a
special appearance and nothing else; and obviously only in buffers where
it was actually enabled.  Don't confuse it with `magit-wip-save-mode'.

This commit removes the special appearance temporarily, but in a few
commits that will be restored.  Unfortunately this use of the existing
"ref formatting" code prevents changes to that code, which forces us to
do it like this.

The special appearance won't be restored exactly as it is now: it will
drop the "(WIP) " prefix.  No other "labels" for other kinds of refs use
such a prefix, and it also isn't necessary, because we already use a
different face to give it distinct look.  Also in a few commits, the
ability for users to add such a prefix using the Custom interface will
be added for all ref namespaces, not just this particular one.  But we
won't use it for any refs by default.

There will also soon be a Custom option that allows hiding certain refs.

By removing this mode we lose the ability to only give "refs/wip/BRANCH"
a special appearance in certain buffers instead of all.  However it soon
will be possible again to give these refs the fallback appearance by
customizing an option.

I don't really think this is a loose at all: if such refs exist then
that most likely means that the user makes use of `magit-wip' and/or
`git wip'; and would like them to have a special appearance everywhere
or nowhere.  If he doesn't use these tools but uses the namespace for
some other reason and doesn't want them to look any different, then
again he can just customize the option.

If the user does use `*wip' in some repositories and wants them to have
a special appearance there, but also uses refs in the same namespace for
other purposes in other repositories, then he is doing it wrong and we
shouldn't keep the mode just so that he can keep on doing that.  Just
saying, I don't expect anyone actually does that.
magit-format-ref-label: don't abuse it for filtering

The last few commits were already preparing for this; here we just make
it final: Do not abuse `magit-format-ref-label', which is supposed to
put nice colors on refs and possibly change their text for display, to
also _filter out_ certain refs.  Performing an additional, completely
unrelated task, made this function unreadable, and required the addition
of several functions and a hook variable.  Remove those that remained
until now.

There is a mechanism dedicated to the filtering of refs:
`magit-list-interesting-refs'.  (That also has issues but that is
a different story).

This isn't perfect yet.  E.g. the involved faces are still named
`magit-log-head-label-{*}'; which isn't good because this, now that
sanity has been restored, could be used elsewhere (but isn't yet).  Also
these faces don't have anything to do with the HEAD, so it makes little
sense that their names contain "-head-".
magit-refs-namespaces: make customizable
magit-refs-namespaces: add rule for git-wip refs
magit-refs-namespaces: improve rule for patches refs

Previously the label text for a ref "refs/patches/SOMETHING" was
"patches/SOMETHING".  We don't do that for any other ref namespace, and
I think this was only done this way because of limitations with the old
code and not because someone actually wanted the prefix to be displayed.
Regardless this makes this namespace consistent with the others, and if
someone wants to keep this prefix, or all prefixes, then she can
customize this option.
Merge branch 'pr/refspace'