gc: find all the dirty bits

gc: find all the dirty bits

When performing garbage collection on schedule because the
min_gc_interval has expired, a check is made to see if garbage
collection can actually be skipped (garbage collection is a
somewhat expensive undertaking after all).

If no refs in the repository have been changed since the last
garbage collection and we've performed garbage collection more
recently than the last time any of our "parents" did (if we're
a fork with alternates), then we can skip.

But, if we've passed all the "skip" tests and it ought to be okay
to skip garbage collection, we do one more test in that case --
we check to see if the repository is "dirty" and if so do NOT skip
garbage collection after all.

In the past the "dirty" check just looked for any loose objects or
more than one pack.  But that's not always good enough.

Enhance the check when no loose objects are found but exactly one
pack (excluding special ignored pack names) is found.

If the single pack has an oddball name (i.e. doesn't match
pack-[hexdigit]{40}.pack) or it's an okay name but the repository
doesn't actually have any refs then consider it to be dirty.

This check now catches interruptions of "gc.sh: the new order"
(0df1370df327fbc3, 2017-12-16) that may have left behind an oddly
named pack and for some reason the lastgc date fails to trigger
garbage collection like it should (it shouldn't have been updated
if garbage collection was interrupted prematurely).

It also now catches a normal "gc.sh: the new order" completion that
may have left a single, oddly named pack behind as part of normal
operation (a single pack of "loose" objects for example) that does
need to be processed further at the next min_gc_interval even if
no refs have been changed since it was created.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>