for-each-ref: add --pretty with format_commit_message as the formatter

--format is pretty limited command to "git log --format". For example
it does not support coloring or alignment. Introduce --pretty, which
combines --format and git-log's one. In --pretty:

 - all format's %(atom) are available. They also accept some pretty
   magic. For example you can use "% (atom)" to only display a leading
   space if the atom produces something.

 - %ab to display a hex character 0xab is _not_ available as it may
   conflict with other pretty's placeholders. Use %xab instead.

 - many pretty placeholders are designed to work on commits. While
   some of them should work on tags too, they don't (yet).

 - Unsupported atoms cause for-each-ref to exit early and
   report. Unsupported pretty placeholders are displayed as-is.

 - Pretty placeholders can not be used as a sorting criteria.

--format is considered deprecated. If the user hits a bug specific in
--format code, they are advised to migrate to --pretty.
for-each-ref: teach verify_format() about pretty's syntax

Pretty format accepts either ' ', '+' or '-' after '%' and before the
placeholder name to modify certain behaviors. Teach verify_format()
about this so that it finds atom "upstream" in, for example,
'% (upstream)'. This is important because verify_format populates
used_atom, which get_value() and populate_value() later rely on.
for-each-ref: introduce format specifier %>(*) and %<(*)

pretty placeholders %>(N) and %<(N) require a user provided width N,
which makes sense because the commit chain could be really long and
the user only needs to look at a few at the top, going to the end just
to calculate the best width wastes CPU cycles and makes Git feel slow.

for-each-ref is different. The display set is small, and we display
them all at once. We even support sorting, which goes through all
display items anyway. This patch introduces new %>(*) and %<(*), which
are supposed to be followed immediately by %(something) (i.e. original
for-each-ref specifiers, not ones coming from pretty.c). They
calculate the best width for the %(something), ignoring ansi escape
sequences if any.
for-each-ref: introduce %(HEAD) marker

'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature.  So, extend the format with
%(HEAD) to do exactly the same thing.

Now you can use the following format in for-each-ref:

  %C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)

to display a red asterisk next to the current ref.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
for-each-ref: introduce %(upstream:track[short])

Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by the contrib/completion/git-prompt.sh).

Now you can use the following format in for-each-ref:

  %C(green)%(refname:short)%C(reset)%(upstream:trackshort)

to display refs with terse tracking information.

Note that :track and :trackshort only works with upstream, and errors
out when used with anything else.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
for-each-ref: improve responsiveness when %(upstream:track) is used

Before anything is printed, for-each-ref sorts all refs first.  As
part of the sorting, populate_value() is called to fill the values in
for all atoms/placeholders per entry. By the time sort_refs() is done,
pretty much all data is already retrieved.

This works fine when data can be cheaply retrieved before
%(upstream:track) comes into the picture. It may take a noticeable
amount of time to process %(upstream:track) for each entry. All
entries add up and make --format='%(refname)%(upstream:track)' seem
hung for a few seconds, then display everything at once.

Improve the responsiveness by only processing the sorted atom (*)
during sorting phase. All others, including upstream:track especially,
will be processed at display phase, each ref line will be displayed
with a delay.

(*) This is not entirely correct. If you sort by an atom that needs
object database access, then it will fill all atoms that need odb.
Which is not a bad thing. We don't want to access odb once at sorting
phase and again at display phase.
for-each-ref: add --[no-]column option
for-each-ref: add --contains
for-each-ref: add --[no-]merged
for-each-ref: resolve HEAD only once
for-each-ref: add --show-detached
branch: reuse for_each_ref for listing branches

TODO: get_get_head_description(), coloring