Revert "Support getting GitHub API v2 tokens when configuring a repository."

This won't be needed with the new hosting service coming up.
Bundle a modified Django 1.3.1 admin change_form.html.

This modified version gives us the field_sets block, which is present in
Django 1.4. This allows us to easily override the fieldsets listed in
the form, in order to use our siteconfig template.

This won't be needed in Review Board 1.7, which will already have this
present.
Add support for hosting services.

This introduces top-level support for hosting services. Previously,
Review Board had a basic concept of hosting services when configuring a
repository. They were nothing more than some pattern matches that
provided helpful fields for configuring a repository's information.

Now, we have a top-level concept of a hosting service. Subclasses of
HostingService are used to provide specific configuration forms for
repositories, provide an ability to request an authorization token from
the hosting service, and provide basic file access.

The various fields (such as a GitHub repository name or whether it's a
public personal account or a private organization) are now stored along
with the Repository in its new extra_data field. This is used later for
both repository access and configuration.

When setting up a repository for a hosting service, the user is expected
to link an account or use an existing linked account for that service.
When linking an account on hosting services that require authorization,
Review Board will perform the authorization request and, if successful,
store any service-specific tokens or data in the HostingServiceAccount
model.

All the existing hosting services have been moved into HostingService
subclasses. Existing configurations will no longer show a hosting
service tied to the account. Instead, they will just appear as custom
repositories. Users are always free to reconfigure their accounts.

GitHub is the first hosting service we support in an extended way. We
get an authorization token, store it, and use it for file requests with
their v3 API.

TODO:

* Fix bug trackers. Right now, the code is temporarily disabled. I will
  be moving to custom forms for configuring this, just like we have with
  repository configuration now.

* Auto-generate an SSH key when needed, and upload to the account.

* Unit tests.

What I have currently is unlikely to change much (aside from comments in
reviews), so look through it and see if things look sane.
Add is_authorized for determining if an account's authorization is valid.

HostingService.is_authorized returns whether or not an account is
authorized, based on the known data. This can be used when changing an
account's authorization method (for example, to change the hosting
service API that Review Board uses, or implementing one for a service
that doesn't yet use one) in order to flag that users need to
re-authorize.

GitHub uses this to make sure that the authorization data and token are
in the saved authorization data.
Move all repository field population to HostingService.get_repository_fields.

Previously, the RepositoryForm was handling filling out the various
repository fields based on form input. Now, that has moved to
HostingService as a convenience, reducing the knowledge RepositoryForm
has.
Properly present hosting services that don't need authorization.

Hosting services that don't need authorization will no longer show the
Account Password field. It's hidden and won't be processed.

Along with this, I fixed RepositoryForm not factoring in the LocalSite
when creating the account. Uniqueness for this is now enforced at the
model layer.
Fix all known remaining issues with hosting service defaults and saving.

Hosting service defaults should now be set correctly when loading an
existing repository and when switching between various settings on the
form.

It's a lot more flexible now with different types of hosting services.
It works fine whether or not the service supports different hosting plans,
and handles validation properly across all the sub-forms.
Add unit tests, and fix the various issues that were found.

Unit tests for hosting services have been added. These check repository
field population for all the hosting services, tests authorization
requests and storage for GitHub, and tests general usage of the
RepositoryForm with hosting services.
Add the hosting service info to the Repository admin list display.

The hosting service info is now listed with the Repository entries in
the admin list page. This makes it much easier to see at a glance which
repositories are used with which hosting services and accounts.
Integrate bug tracker configuration with the hosting service support.

The repository form now allows for configuration of bug trackers again.
The possible trackers are pulled from the list of hosting services.

A hosting service can now specify whether it supports repositories, bug
trackers, or both. There's a mixture now of each type. Bugzilla, Trac,
and Redmine services have been added, and are all currently for bug
trackers only.

Some of the fields in HostingService (repository_form, repository_plans)
have been changed to be more generic. Some new functionality has also
been added to make it easier to query for the information we need.

The repository form, of course, is the bulk of this work. Like a
repository's hosting service, all the field data is stored in
Repository.extra_data. This reuses the same forms that repository
configuration use, but adds a "bug_tracker-" prefix to the keys.

Unlike with repositories, though, there's no concept of linking an
account. Instead, there's just a username field, when the bug tracker
needs it. In the future, when we need deeper integration into bug
trackers, that may change, though we'll need to promote bug trackers to
being more like repositories, and change the configuration workflow a
bit.

Existing bug trackers will not be categorized under the service type.
They will all appear as Custom. It would be possible to reverse-map it,
like we used to, but it will get it wrong in many cases (such as with
GitHub, as each plan's bug tracker's pattern is interchangeable).

Right now, all the configuration continues to update the
Repository.bug_tracker field, which is still used for all display. We
will probably want to change that down the road to dynamically compute
the bug tracker URL on demand, since it's possible for those URLs to
change in a HostingService in new releases. That needs some thought,
though.

Unit tests have been added for bug tracker field testing, the new
hosting services, and bug tracker field population and saving in
RepositoryForm.
Merge branch 'hosting-services' into release-1.6.x