High Level OpenPGP v6 Key Generation

[vanitasvitae]

Hey!
In this PR, I'm working on a high-level API for OpenPGP key generation (v6 only for now).
Let me know, what you think of the design sketched out in OpenPGPV6KeyGenerator :)

I tried to keep the API straight-forward, but still allow modifications of the (hashed) signature subpacket areas by the use of callbacks which the user can hook into, to modify the signature subpackets prior to signature generation.

The PR also adds key generator classes for individual keys, such that the risk of making mistakes during key generation (e.g. using wrong/weak parameters) is minimized.

I used PGPainless as orientation for the API design, but kept the generation API a bit slimmer for now. Let me know what you think of the direction the API is heading.

[vanitasvitae]

I'm contemplating whether to transform the OpenPGPV6KeyGenerator into a general OpenPGPKeyGenerator class, where the user can specify the key version number.

There are some non-trivial differences between v4 and v6, most notably the fact that v6 stores preferences in a Direct-Key signature, while v4 prefers user-id certification signatures (at least if you want to be compatible to GnuPG).

[vanitasvitae]

Ready for review. Let me know if I can make your job easier by squashing or splitting this up into smaller PRs :)

[vanitasvitae]

One thing I dislike about the current API design:
PGPKeyPair by default contains a primary key. Ideally I'd like to deal with an untyped key pair, whose type is determined when the key pair is added to a key ring.
Of course, you could manually convert between key types by converting the public key packet into a PublicSubkeyPacket object, and I even added PGPPublicKey.asSubkey() for this purpose, but that's still something the user needs to know.

An additional issue with the current API is, that PBESecretKeyEncryptor instances that use AEAD rely on the public key's packet tag to derive the KEK (key encapsulation key), so the key type has to be properly set the moment the PBESecretKeyEncryptor is instantiated.

I'm not sure, if there is a clean way to refactor the current API, circumsailing these rough edges in a backwards-compatible way.