Change-Id: I5298c93e03099813f5713a4effd87913429aa3dc

The mirror executor will fetch ref updates for repository mirrors.  This
feature is disabled by default and can be enabled by setting
git.enableMirroring=true.  The period between update checks is
configurable, but it is global.  An individual rpeository may not set
it's own update schedule.

Requirements:
1. you must manually clone the repository using native git
   git clone --mirror git://somewhere.com/myrepo.git
2. the "origin" remote must be the mirror source
3. the "origin" repository must be accessible without authentication OR
   the credentials must be embedded in the origin url (not recommended)

Notes:
1. "origin" SSH urls are untested and not likely to work
2. mirrors cloned while Gitblit is running are likely to require
   clearing the gitblit cache (link on the repositories page of an
   administrator account)
3. Gitblit will automatically repair any invalid fetch refspecs with a
   "//" sequence.

Change-Id: I4bbe3fb2df106366ae4c2313596d0fab0dfcac46

Change-Id: I9f91138b20219be6e3c4b28251487df262bff6cc

Gather logic for building the path/name of a personal user repository into one class.

This is a massive commit which reorganizes the entire project structure
(although it is still monolithic), removes the Build classes, and
switches to Moxie, a smarter Ant build tookit based on the original
Gitblit Build classes.

The Ant build script will likely require additional fine-tuning, but
this is big step forward.

Present the mutable permissions by default.  Allow the administrator or
owner to toggle the displayed permissions to see how the user
and team permissions are applied to a repository.

The order of permissions defined within a user or team is preserved
during read and write.  This order is important for determining the
regex match used within the user or team object.

If the user is an admin or repository owner, then RW+
Else if user has an explicit permission, use that
Else check for the first regex match in user permissions
Else check for the HIGHEST permission from team memberships

If the team is an admin team, then RW+
Else if a team has an explicit permission, use that
Else check for the first regex match in team permissions

If this feature is enabled then permitted users can automatically create a
repository when pushing to one that does not yet exist.  Permitted users
are administrators and any user with the CREATE role.

If the pushing account is an administrator, the created repository may be
located in any folder/project space.  This reposiory will inherit the server's
default access restriction and authorization control.  The repository owner
will be the pushing account.

If the pushing account is a regular user with the CREATE role, the repository
can only be located in the account's personal folder (~username/myrepo.git).
This repository will be VIEW restricted and accessible by NAMED users.  The
repository owner will be the pushing account.

There are now three new targets on the ANT build:
- buildJAR: creates a GitBlit JAR including the GitBlit biz logic
- installMaven: install GitBlit JAR as Maven module
- uploadMaven: uploads GitBlit JAR to a Maven repository

Additional extensions have been made to allow:
a) GitBlit to load his resources outside of Wicket domain
b) GitBlit to use an injected UserService
c) Generic authentication of HTTP Request using 3rd party logic
d) Load settings programmatically from an InputStream
e) Use cookie authentication OR generic HTTP Request
   authentication for Wicket pages
f) UserModel with branch-level security logic

Implemented discrete repository access permissions to replace the
really primitive course-grained permissions used to this point.  This
implementation allows for finer-grained access control, but still
falls short of integrated, branch-based permissions sought by some.

Access permissions follow the conventions established by Gitosis and
Gitolite so they should feel immediately comfortable to experienced
users.  This permissions infrastructure is complete and works exactly as
expected.  Unfortunately, there is no ui in this commit to change
permissions, that will be forthcoming.  In the meantime, Gitblit
hot-reloads users.conf so the permissions can be manipulated at runtime
with a text editor.

The following per-repository permissions are now supported:
- V (view in web ui, RSS feeds, download zip)
- R (clone)
- RW (clone and push)
- RWC (clone and push with ref creation)
- RWD (clone and push with ref creation, deletion)
- RW+ (clone and push with ref creation, deletion, rewind)

And a users.conf entry looks something like this:

	[user "hannibal"]
		password = bossman
		repository = RWD:topsecret.git

The fork mechanism clones the repository , access restrictions, and
other config options.  The app has been updated throughout to handle
personal repositories and to properly display origin/fork links.

In order to fork a repository the user account must have the #fork role,
the origin repository must permit forking, and the user account must
have standard clone permissions to the repository.

Because forking introduces a new user role no existing user accounts can
automatically begin forking a repository.  This is both a pro and a con.

Since the fork has the same access restrictions as the origin repository,
those who can access the origin may also access the fork.  This is intentional
to facilitate integration-manager workflow.  The fork owner does have the
power to completely change the access restrictions of his/her fork.

Add code / test to defend against LDAP injection attacks.

Teams simplify the management of user-repository access permissions.  Teams have a list of restricted repositories.  Users are also added to teams and that grants them access to those repositories.

Federation and RPC support are still in-progress.

Repository owners no longer have to be explicitly selected to grant
them access to Git, feeds, and zip downloads. Idea from Github/dadalar.