Add OpenSSL.crypto.verify_chain method.

This change adds support for verifying a certificate or a certificate
chain. This implementation uses OpenSSL's underlying X509_STORE_CTX_*
class of functions to accomplish this.

This change also adds an intermediate signing certificate/key and a
service certificate/key signed with the intermediate signing
certificate, to make testing the OpenSSL.crypto.verify_chain method
easier to test. I figured I would add it to the top level module so
other people can use an intermediate signing certificate in their own
tests.

Issue: https://github.com/pyca/pyopenssl/issues/154
Lines 2320 - 2325 are adding application logic on top of the OpenSSL API.  I prefer to avoid this where possible.  I suggest providing a thinner layer wrapping this OpenSSL API instead.

It's a little bit difficult for me to see what exactly that thinner layer should be since this particular OpenSSL API seems confusing and overly complicated and to cross a couple layers (at least one of which I also don't really understand - what is an `X509_STORE_CTX` and why is it a different thing from an `X509_STORE`?).

My first guess would be that the API should be more like `X509Store.verify(certificate, additional_certificates=None, crls=None, verify_param=None, default=None)`.  Though I must add that I don't really know what an `X509_VERIFY_PARAM` is, nor what the point of `X509_VERIFY_PARAM_lookup` (with which the string value for  `default` would be used) is.  Potentially all these extra arguments could be added later in a follow-up issue - but it does strike me that they are necessary for a complete wrapping of this functionality (which, again, maybe wrong - seeing as how I don't actually know what all these parameters control).

It may also be that what's actually appropriate is to have an `X509StoreContext` type with a `verify` method - along with `set_chain`, `set_param`, `set_default`, etc methods.  This would parallel the way other classes have been defined in pyOpenSSL.

What would be really nice is to get input from someone who is actually somewhat familiar with this collection of APIs (in particular, with the `X509_STORE` and `X509_STORE_CTX` structure) to explain what the general idea is here.  Without an understanding of the big picture or the abstract problem these APIs are supposed to be solving it's difficult to design a good API (even if that API isn't supposed to be novel and is only supposed to re-expose the existing OpenSSL API).