Advanced DH support

[wiomoc]

This implements the functionality to generate the keys needed and use them for key derivation
closes #498

[stbuehler]

Taking or returning 3 values of the same type in a function seems always bad to me, because you are gonna screw up the order eventually. Perhaps this should be wrapped into structs (one for owning them, one for borrowed values)?

You also should add some doc comments for the functions in the openssl crate (but not openssl-sys); usually a short text what it does and a reference to the openssl man page.

[stbuehler]

This breaks the public API. How about providing this variant as a new function (and use the new function to implement the old one by simply wrapping q in Some(...))?

[stbuehler]

Mostly looking good to me now.

I think removing Result<...> from accessors was the right choice; those shouldn't fail with a consistent state, which the rust types should ensure.

We'll see what sfackler thinks about DhParamsRef; perhaps another alternative to returning a tuple would be standalone accessors (prime_p, prime_q, generator?).

The local DH_get0_pqg implementation doesn't handle returning only partial data yet like DH_get0_key (the openssl does I think); as long as this isn't used it probably doesn't matter.

Tests still fail as transpose wasn't stable in rust 1.31.0 (the current min version; I think sfackler considers raising it breaking the API).

[sfackler]

I think it's probably best to follow the convention used by e.g. the Rsa type and have separate accessors for the different components.

While I do in crease the MSRV over time, I like to keep it where it is where possible. In this case it's easy to work around the lack of transpose so I'd just not use the method.