Make it possible to specify alternative certificate chains

[GregBowyer]

Twine is amazing in that it actually allows the end user to validate the
SSL when items are being uploaded to a specific pypi repository.

Unfortunately, this validation will only occur for the authorities that
are specified in certifi. This limits two important use cases for
internal and none standard pypi servers:

1. There is no method to use an alternate certificate authority chain,
   such as, for instance, is presented from a custom CA root
2. There is no method to use client certificates, which can be an
   alternative to username and password.

This commit seeks to redress this, by allowing both of these options to
be specified, with configuration that mirrors that of pip.

[sigmavirus24]

Hey @GregBowyer this is great. Can I make a request for a different way to structure this though?

The certificate root and client certificate information isn't really intrinsic to a Repository object. The Repository object just happens to manage a Session instance from requests. So, I think I'd rather see two methods added that handle this for us:

class Repository(object):
    # ...
    def set_certificate_authority(self, cacert):
        if cacert:
            self.session.verify = cacert

    def set_client_certificate(self, client_cert):
        if client_cert:
            self.session.cert = client_cert

And then have this used as

repository = Repository(config["repository"], username, password)
repository.set_certificate_authority(cacert)
repository.set_client_certificate(client_cert)

I'm anticipating that people are using (or will start using twine) as a library as well as a command-line utility. As such, I'd like Repository to be very clean as a public API.