(PE-4372) Added utilities for alt dns names

* Able to add extensions to a CSR
* Added utilities to create an Alt. DNS names extensions

This PR is for review only so people can start taking a look at it while I write some tests.
I agree we should not leak implementation details through the API, but I don't know if I consider this to be a leak (assuming this is a valid part of the API, which may be debatable).

The idea with these predicates is that they allow you to talk about specific domain objects without referring to the implementation of those objects.  Maybe this isn't something that we necessarily intend users of the API to be doing that often, but it's certainly been valuable at least in the implementation of the API, as you can see all the pre/post conditions using this (tests as well).  Given that, I might argue they do the opposite of the leaking BouncyCastle - they hide the fact that we're dealing with the BouncyCastle implementation while allowing you to concretely identify whether an object is a certificate request that will work when you give it to an API function that takes one.

If we didn't have this predicate, we'd have to change the pre/post conditions of API functions to instead work with `PKCS10CertificationRequest` objects, and likely reflect this in the docstring.  That would be leaking the implementation in my mind.  Instead, if we used this predicate instead of referring to the class name, then we can at least isolate the BouncyCastle leakage to the predicate, and speak in more general terms in the docstrings in the same way that you would with something like the `reader` and `writer` functions - e.g. "parameter must be something that is supported by `reader` or `certificate-request?`".

This shouldn't block this PR - just giving my thoughts at this time.
 
I wonder if we would have given as much thought to all this if this was just another namespace in jvm-puppet...probably not :D