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.

symbolic head and available heads.

Added convenience methods to JGitUtils to support retrieving available
heads as List<String>.
When resolving the symbolic head target as a String, if the head is
detached, attempt to match the commit SHA1 against the known tags, using
the most recent tag if more than one matches.
Revised error messaging to better reflect actual outcome.
Adjusted tab indexes on edit repository page to include default head combo
box.
Updated message key for default head combo box to use uppercase "HEAD".

This allows control over the default branch after clone, which is equivalent to running:
  git symbolic-ref HEAD refs/heads/mybranch

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.

Trap connect exceptions.