Add repository path, SCMTool, SSH key and HTTPS certificate verification.

This change introduces a number of new additions to the Repository
creation/editing form and SCMTools that help ensure that the repository
is configured correctly the first time. We do this by validating that
the repository path is good, the SCMTool has all its dependencies installed,
and that the SSH or HTTPS connection is valid and verified.

Each SCMTool has lists of dependencies, both Python modules and binary
executables, that are checked in the form during the validation step.
If any dependencies are missing, we present the list to the user so that they
must install the dependencies before saving the repository. Users should no
longer be in a situation where they've configured a repository and then ended
up confused later because p4 or something isn't found in the path.

After SCMTool verification, we begin the repository verification.

If the repository is behind an SSH connection, then we grab the host key
(using the Paramiko Python module) and then see if it's known. If it's an
unknown key, then we present the key to the user, much like ssh would. They
can choose to indicate that they trust it (which will save in the
~/.ssh/known_hosts file), or they can go back and re-edit the repository
information.

If the key is a "bad" key (the key we get is different tan what is recorded
in the known_hosts file) then we warn the user, indicate that it may be
malicious, and show the recorded key and the new key returned. Like with the
unknown key, we allow the user to indicate they trust the host, or they
can go back and re-edit the info. If they trust the new key, we replace it
in the known_hosts file.

If the repository is on an HTTPS connection, and the certificate wasn't
previously verified, then we present the certificate, along with any
warnings (such as it not matching the host name or not being from a trusted
certificate authority). The user is presented with the same choices as with
the SSH key.

Unlike the SSH support, the HTTPS support is not centralized around a common
API and a known_hosts file. It is up to each SCMTool that supports certificates
to handle grabbing the certificate information and to accept it. Right now,
only SVN supports this. It's far more tricky with Git (and would require
a dependency on curl and pyCurl), but hopefully less common as well.

Once all the above is checked, we attempt to connect to the repository to
verify that it is indeed a valid repository. If this fails, we present the
error to the user.

Tested unknown SSH keys, bad SSH keys, and already known SSH keys.

Tested HTTPS certificate verification with Subversion.

Tested the following URL types on the following repository types:

Bazaar: bzr://. bzr+ssh://
CVS: :pserver:, :ext: (for SSH)
Git: http://, git://, ssh://, user@host:/path/, user@host:~path/, user@host/path/, /local/path
SVN: http://, https://, svn://, svn+ssh://

The other types had minimal changes, so I didn't do extensive testing. Mercurial, Monotone, Clear Case and Perforce don't yet support verification.

Tested both binary executable and Python module dependencies.