Make `Certificate` / `TrustStore` types non-backend specific

[jvdprng]

As per https://discuss.python.org/t/pre-pep-discussion-revival-of-pep-543/51263/45

On my final look at the current structure, I have a vague concern that we could accidentally push users into having a tricky time matching types, particularly if Certificate and TrustStore are meant to be backend-specific. I may be wrong, but it feels like we want pure data all the way up to ServerContext and ClientContext, and then the backend decides how to handle it.

(A specific example: I see that OpenSSLCertificate.from_buffer creates the temporary file and then returns an instance with reference to the filename. I think it’s better to keep the buffer at that point and have the _configure_context... functions create a file if needed. This way, Certificate can be a concrete type, possibly with a mechanism for smuggling extra key/values to a known backend.)

A hypothetical example: if we made a WindowsCertificate class that creates the CERT_CONTEXT immediately and loads the certificate in, that object is now functionally incompatible with certain backends, despite being type compatible (modulo all the type checking stuff that I just ignored). But a concrete Certificate that doesn’t load the certificate immediately would be fully compatible with either, and it removes the temptation to create incompatible types.

[jvdprng]

See https://github.com/trailofbits/tlslib.py/pull/56

[woodruffw]

I'm +1 on making these pure/non-backend-specific: I agree with Steve's argument that tying them to the backend is likely to cause user confusion/errors/type mismatches for relatively little benefit.