allow non-gitolite keys to have options/command, etc

Apparently, ssh-keygen can take fingerprints of entire authkeys files
also.  This is totally undocumented.

Since 'man ssh-keygen' only says: "Show fingerprint of specified public
key file." and makes no mention of authorized_keys files, I had assumed
that it treated a file containing this

    command="/usr/bin/backup" ssh-rsa .....

(i.e., a non-gitolite key that nevertheless contains a command) as just
a special type of pubkey file.  This meant, to me, that the presence or
absence of a newline should not matter, because *without* the 'command='
it certainly doesn't.

But what's actually happening is that it is treating this as an
authorized_keys file, and in *that* mode, it requires a newline.

I still don't see why it should require a newline as a *terminator*;
having it as a *separator* should be sufficient, but it's pointless to
argue about that when the feature itself is undocumented.

Wizmaster (code at wizmaster at fr) had to dig into the openssh source
code to figure this out and explain it to me.
Fix a warning about ambiguous shift usage

[committer's note: newer perl's don't have this problem, but 5.8.8 at
least appears to require the parens]
(minor) change urls to fit new domain gitolite.com
remove restriction on @ in setup -pk
(minor) README docfix about empty config values

(this should have been part of d8df4a9)
rc file format change (please read below)

First: if you have an old rc file it will still work.  In fact
internally the new rc file data gets converted to the old one.  So you
do not have to do anything normally.

This changes the rc file in the following way, taking mirroring as an
example.  Simple enough for most purposes but you really should read the
documentation...

old:
    INPUT                       =>
        [
            'Mirroring::input',
        ],

    PRE_GIT                     =>
        [
            'Mirroring::pre_git',
        ],

    POST_GIT                    =>
        [
            'Mirroring::post_git',
        ],

new:
    ENABLE  =>
        [
        # COMMANDS
            ... several commands ...
        # Triggers
            ... several triggers ...
            'Mirroring',
        ],
rc file format change: some inline doc/help text fixups
refex-expr
v3.4
minor but ugly bug in refex expression sugar code
add a contributing document

text is pulled out of the wiki.  This will enable github to show a link when
a contributor creates an issue or opens a Pull Request
list-memberships and perms changes:

  - list-memberships now requires a '-r' or '-u'; i.e., you have to
    explicitly state whether you are passing a reponame or a username

    see the new '-h' message for details.

  - Easy.pm now has a new 'in_role()' test that is, at present, only
    used by 'owns()', which uses that instead of checking that he is the
    creator.

    The role name used (I recommend "OWNER") must be set in the rc file
    like so

        OWNER_ROLENAME => 'OWNER',

    and if it is not set, defaults to 'CREATOR', which makes it behave
    as things currently do.

  - perms now uses this new 'owns()' function to authorise the user,
    instead of checking that she is the *creator*
new command 'owns' (thanks to Kevin Pulo)

(See 'owns2' in
https://groups.google.com/d/msg/gitolite/InJDugkXY0s/Lxa_gsd_WbUJ)
DEFAULT_ROLE_PERMS replaced by per repo 'default.roles' option
overwrite projects.list atomically

avoids any potential race conditions between triggers being run
concurrently, and probably avoids gitweb picking up a half-done file too
v3.5
(bugfix) (v3.5.1) fix permissions of projects.list file

update-gitweb-access-list had a change recently (289b19d) that had a
side-effect of making projects.list unreadable by other userids (like
'apache' or whatever).

This makes 3.5 unusable for anyone using gitweb.  (Hence the new tag,
too, though 3.5 is only the previous commit and this is a very small
change).
set-default-roles should not kick in always...

should only do its thing when called from someone creating a new wild
repo, and not just changing its perms.  (Because, don't forget, the
POST_CREATE trigger list is invoked from perms also).
'info' should show wild patterns hiding in groups also

(thanks to Sebastian Koslowski for catching this)