This change also ties the plugin manager into the Wicket framework and
allows plugins to contribute and mount new pages which are linked by the
top navbar and repository navbar extensions.

This is the first step towards modularization and injection.  All
direct references to the GitBlit singleton within the Wicket pages
and panels have been replaced to proxy methods in the GitBlitWebApp
singleton.  There are still two Wicket classes which rely on the
GitBlit singleton; those require manual instantiation (servlet 3).

Change-Id: I0cdbbcf87959d590c446c99abb09c07c87c737bc

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.

This mechanism bypasses the standard Wicket redirect mechanism because it
turns out that the servlet container reencodes Wicket's relative redirect urls.
This results in another way that parameters with forward-slashes can be borked.

Bad, bad servlet container.

org.eclipse.jetty.server.Response#L447: String path=uri.getDecodedPath();

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.