This change revamps our Add/Change Repository pages to easily allow for specifying a repository that lives on SourceForge, Google Code, or Bitbucket. It also allows for selecting a bug tracker on Bitbucket, Bugzilla, Google Code, Redmine, SourceForge, or Trac.

Depending on the options selected, the list of supported repository types will be changed to reflect what's available on that service, and the fields available will change. For example, Google Code will present a field for the project name. The user can always choose Custom to specify their own paths.

The bug tracker selection works similarly. The fields presented are related to that specific tracker. Each field has help text to tell the user what they need. There's also a "Use hosting service's bug tracker" checkbox that is enabled for certain hosting providers. Checking this will grey out the bug tracker selection, and will use whatever bug tracker is associated with their project on the hosting service.

When creating a new repository, the project name fields (for Google Code, etc.) will be automatically entered as the user types in a repository name. If the user goes to change the project name manually, updating the repository name will no longer cause updates to these fields. This can be useful when using the project name as the repository name, saving the user some extra typing.

Internally, we have a nice list of known hosting services and bug trackers. This list contains the supported repository types, fields, and format strings for populating the database based on these fields. From this, we can reliably enter valid values (saving the user from having to specify things like "%s" in most cases) and we can also determine the proper hosting provider, bug tracker, project name, etc. based on the values saved in the database (by parsing the database values using the format strings). This prevents us from having to store extra data in the database, and also means that existing setups using Bugzilla, SourceForge, or whatever will actually say Bugzilla, SourceForge, etc. on the page the next time they go to it.

Went through and created a bunch of repositories with different hosting services, repository types, and bug trackers.

Tested all the interaction for auto-populating entries, parsing existing paths, updating fields based on selections, and saving values to the database.

I'll be working on some unit tests after this that cover all these cases more reliably. Some of these will be done using Selenium, once I finally get that infrastructure in and proper build VMs set up.