t1411: add more selector index/date tests

We already check that @{now} and "--date" cause the
displayed selector to use the date for both the multiline
and oneline formats. However, we miss several cases:

  1. The --format=%gd selector is not tested at all.

  2. We do not check how the log.date config interacts with the
     "--date" magic (according to f4ea32f, it should not
     impact the output).

Doing so reveals that the combination of both (log.date
combined with the %gd format) does not behave as expected.
log: respect date_mode_explicit with --format:%gd

When we show a reflog selector (e.g., via "git log -g"), we
perform some DWIM magic: while we normally show the entry's
index (e.g., HEAD@{1}), if the user has given us a date
with "--date", then we show a date-based select (e.g.,
HEAD@{yesterday}).

However, we don't want to trigger this magic if the
alternate date format we got was from the "log.date"
configuration; that is not sufficiently strong context for
us to invoke this particular magic. To fix this, commit
f4ea32f (improve reflog date/number heuristic, 2009-09-24)
introduced a "date_mode_explicit" flag in rev_info. This
flag is set only when we see a "--date" option on the
command line, and we a vanilla date to the reflog code if
the date was not explicit.

Later, commit 8f8f547 (Introduce new pretty formats %g[sdD]
for reflog information, 2009-10-19) added another way to
show selectors, and it did not respect the date_mode_explicit
flag from f4ea32f.

This patch propagates the date_mode_explicit flag to the
pretty-print code, which can then use it to pass the
appropriate date field to the reflog code. This brings the
behavior of "%gd" in line with the other formats, and means
that its output is independent of any user configuration.
reflog-walk: clean up "flag" field of commit_reflog struct

When we prepare to walk a reflog, we parse the specification
and pull some information from it, such as which reflog to
look in (e.g., HEAD), and where to start (e.g., HEAD@{10} or
HEAD@{yesterday}). The resulting struct has a "recno" field
to show where in the reflog we are starting. It also has a
"flag" field; if true, it means the recno field came from
parsing a date like HEAD@{yesterday}.

There are two problems with this:

  1. "flag" is an absolutely terrible name, as it conveys
     nothing about the meaning

  2. you can tell "HEAD" from "HEAD@{yesterday}", but you
     can't differentiate "HEAD" from "HEAD{0}"

This patch converts the flag into a tri-state (and gives it
a better name!).
reflog-walk: always make HEAD@{0} show indexed selectors

When we are showing reflog selectors during a walk, we infer
from context whether the user wanted to see the index in
each selector, or the reflog date. The current rules are:

  1. if the user asked for an explicit date format in the
     output, show the date

  2. if the user asked for ref@{now}, show the date

  3. if neither is true, show the index

However,  if we see "ref@{0}", that should be a strong clue
that the user wants to see the counted version. In fact, it
should be much stronger than the date format in (1). The
user may have been setting the date format to use in another
part of the output (e.g., in --format="%gd (%ad)", they may
have wanted to influence the author date).

This patch flips the rules to:

  1. if the user asked for ref@{0}, always show the index

  2. if the user asked for ref@{now}, always show the date

  3. otherwise, we have just "ref"; show them counted by
     default, but respect the presence of "--date" as a clue
     that the user wanted them date-based