This introduces modern certificate support for all hosting services.

The work required for this is a bit different than just using a

cert-populated SSL context for urlopen(), as hosting services

historically have supported storing approved SSL certificate data as

part of the HostingServiceAccount. Those were conducted with hostname

checks turned off. That added a bit of complexity and required a

migration path.
Now, when preparing to open an HTTPS request where legacy cert data is

present, that data will be converted into a Certificate. If that

certificate's associated hostname (either the Common Name or any

Subject Alternative Names) is a match for the address, then it will be

saved as a new certificate and the legacy data removed. If there are any

problems, the legacy data will be used with a legacy SSL context

disabling hostname checks, logging warnings until the admin deals with

the problem.
For testing, some changes needed to be made to testing infrastructure.

A utility SSL context for the CertificateManager tests has been made

commonly available as CaptureSSLContext, and a new test cert has been

added. Along with this, CertificateManager no longer computes the data

directory until it needs it, allowing the test harness to switch that to

a temporary location for the test run.
Hosting services have not yet been updated to raise the modern

CertificateVerificationError. The legacy UnverifiedCertificateError

exception is still supported.

Unit tests passed.
Tested this with a couple of self-hosted services against self-signed

SSL certificates. Verified that I got the right error when I tried to

communicate with a server, and got the trust banner.
Tested that trusting the host added the certificate.
Tested migrating legacy SSL data from a hosting account, and verifying

it added the new certificate.