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.

This is an in-progress feature to offer an interface for grouped
repositories.  This may help installations with large numbers of
repositories stay organized.  It also will be part of a future,
more advanced security model.

* Build script overhaul including building & publishing GO, WAR, Docs,
and Site.
* Restored JGit 0.12.1 dependency and backported Blame.  Got tired of
waiting for JGit 1.0.0 Maven artifacts.
* Changed Summary Page layout
* Optional cookie authentication
* Added icons for log, tags, and branches panels.
* Show last commit author and short message on branches panel.
* Unit testing.
* Documentation.

Settings access has been abstracted and the way is becoming clear to
offer a WAR build in addition to the integrated server stack.  Util
methods moved around.

Right now the implementation is hard-coded to pass the realm into a
singleton.  This won't work for a WAR distribution so I will
need to figure out how to properly authenticate the webapp using form
authentication and the git servlet using basic authentication - host
against the same realm.