mirroring to arbitrary external servers using arbitrary commands

(This was started off by someone on irc wanting to backup his repos to s3
using jgit.)
fixing expand-deny-messages
enforce the full path requirement in 'install'
ssh-authkeys: update authkeys when keydir is present but empty

When ~/.gitolite/keydir is present but empty, and someone runs 'gitolite
trigger POST_COMPILE', gitolite does not clear out the corresponding lines in
~/.ssh/authorized_keys.

----

NOTE that this can only happen when you're managing gitolite directly on the
server, per http://gitolite.com/gitolite/odds-and-ends.html#server-side-admin.

When you're managing gitolite remotely, and you 'git rm -rf keydir' in your
admin clone, then commit and push, this behaviour (of not updating the
authkeys file in ~/.ssh) will remain.

However, it's not by design -- it's more of a lucky accident!  What's
happening here is, when ~/.gitolite is updated via a "git checkout -f", the
(now empty) 'keydir' directory is *completely deleted*.  This makes
ssh-authkeys bail much earlier, because now it looks like a system that is not
even *using* ssh keys (for example, an http-mode installation).

The end result is the same -- the authkeys file is left untouched.  However, I
will not be "fixing" that, for obvious reasons.
allow gitolite.conf to be tested locally!

please see documentation in the code
VREF/NAME_NC -- like VREF/NAME but for "new commits" only
disallow ../ everywhere

This should have been done as soon as I rolled in support for "ua"
(unrestricted arguments; see comments in src/commands/git-annex-shell for
details).

Please also see mailing list thread around this date for more.  In particular,
I need to ackowledge someone who pointed this out in the context of
"symbolic-ref", but whose name/email I appear to have misplaced!
v3.6.2
(minor) fixup due to some (fedora??) path change
(minor) another test fixup

why was I doing this manually till now?
(minor) README fixup