gc.sh: include private friends

gc.sh: include private friends

In the future, Girocco may want to keep extra data around that's
associated with each repository.

There may be a non-trivial amount of it; it may be derived from
the actual content of the repository itself; it may be expensive
to regenerate.

This content should not be (easily) accessible via a clone; its
presence should not alter the result or performance of a clone.

The extra data should be stored efficiently; it should be possible
to retrieve it quickly; it must be able to be pruned and/or expired
reasonably efficiently to keep its use of disk space under control.

To that end, include a "private" subdirectory repository's refs
as "friends" when running gc, but only if that "private" subdir
is a Git repository and its "objects" subdirectory is a symlink
to the repository's "objects" subdirectory but it has its own
distinct refs subdirectory.

In other words, it's a set of "private" refs whose objects are
stored in the repository's objects area.

Even with uploadpack.allowAnySHA1InWant set to false (the default),
it may still be possible to get Git to retrieve the contents of an
object with a known SHA-1 value.  See the discussion of this in
the "SECURITY" section of the gitnamespaces(7) man page (aka
`git help namespaces`).

Despite all that, the gitweb interface will happily display and make
available any objects at all regardless of which ref they may be
reachable from if any at all.

The "private" area is definitely not a "secure" area, but it's not
intended to be.

Nevertheless, any refs in the "private" area are completely protected
(a super version of transfer.hideRefs) from exposure (notwithstanding
exploits to retrieve the object contents of known SHA-1 values or
accessing objects via gitweb) and any ref changes within the "private"
area are completely excluded from any ref change logging or other
notifications that Girocco performs for ref changes to the
repository's refs.

Since objects exclusively reachable via refs in the "private" area
participate in the gc process as "friends", they will be kept in
the separate "Phase II" pack thus not impacting normal repository
operations (the "Phase I" pack will always be searched before the
"Phase II" pack).

With this all in place and a "private" subdir correctly set up, it
becomes trivial to attach various "notes" to objects that can be
easily and quickly retrieved via "helpers" while not being cloneable
(notwithstanding deliberate exploits for known SHA-1 values).

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