Negotiated FFDHE parameters

[ocheron]

After ECDH this is to improve validation in DH key exchange:

• support for named FFDHE groups (RFC 7919), in addition to custom groups we have today
• minimal validation of DH parameters (but which is enough when using named FFDHE groups)
• optional client callback to implement policy about custom groups

When DHE params match a named group, internally module Crypto.IES is used and the
implementation generates short exponents as optimisation.

Unfortunately because of compatibility this means we get 3 sets of APIs with some redundancy:

• Crypto.DH is used when groups are custom
• Crypto.IES has new compatibility functions with data types like in Crypto.DH and removal of leading zeros (TLS <= 1.2)
• Crypto.IES existing hybrid group functions are kept and extended with FFDH validation checks and use of short exponents, so they should still be usable for TLS 1.3

[kazu-yamamoto]

For TLS 1.3, please define/export availableGroups (availableECGroups ++ availableFFGroups.
Except that, this PR looks good to me.

[ocheron]

Thank you for reviewing, I've added availableGroups.
You can merge if you like or I'll do it in a few days.

For information in haskell-crypto/cryptonite#204 I put some measurements about the groups we have.

[kazu-yamamoto]

I have confirmed that my tls13 branch on this works well. So, I have merged this PR.