Allow easier implementation of IX509CertificateDatabase and BouncyCastleSecureMimeContext

[JoeShook]

While implementing IX509CertificateDatabase and extending BouncyCastleSecureMimeContext I ran into a few internal methods I would like to use for consistency. This PR exposes those with code documentation.

I chose this crypto-abstratctions branch because I thought it might be the appropriate place but I could change the PR to the main branch if my changes are acceptable.

I have more PRs. I just want to ensure they are something you are OK with.

Future PR themes I have ready are:

• Ability to find end certificate in IX509CertificateDatabase for signing and encryptiing with techniques other than Email. I work on a OS project called the nhin-d refered to as the Direct Project. It is a SMIME protocol where the public certificates are disoverable in DNS via CERT records. We search by email first replacing the @ symbol with a dot and if not found then we search by domain name. The domain name is the friction I have with todays implementation when trying to find the private key for signing. My first stab at this was to import the certificate into the X509CertificateRecord and use Subject Alt Names of DNS type as a fall back in the GetSubjectEmailAddress extension. Semantically it is not the SubjectEmail but it works when I search.
• Ability to terminate trust as a trust anchor rather than the CA. This is common in the Direct Project and expect it would be in standard SMIME as well. This does involve a way to express that a certificate should be the anchor other than being self signed.
• Intermediate and CRLs downloaded on demand and cached. There was one place where the CRL is downloaded but I added that and the intermediate along with their CRLs also. I do need to put more work into it so it can chase the missing intermediates with many in the chain.
• Maybe add a wrapping feature where we can wrap a message before signing and encrypting using a specific list of headers we want to expose and content-type=message/rfc822. Yes that is specified in the Direct Project as well. Should be comming from rfc 3851. Maybe the code has the mechanics for this already and I just haven't noticed it.

I have a test harness localy where I have ensured I could wrap, sign and encrypt witht he Direct Project reference implementation and the Decrypt with MimeKit and the reverse. In my more modern offline version we use MimeKit heavily for but there is a lot of tranlation between MimeKit and our Direct Project implementation of Mime. This experiment shows me that we could adopt MimeKit as our SMIME api and save a lot in allocations.

Thanks for reading this far and of course thanks for one of the best c# OS contributions.

-- Joe