Require the application to load a polyfill instead.

In terms of API, this feature is backwards compatible, no breaking changes.
However, since a Wasm module is loaded for the Argon2 computation, browser apps
might need to make changes to their CSP policy in order to use the feature.

Newly introduced config fields:
- `config.s2kType` (defaulting to `enums.s2k.iterated`): s2k to use on
password-based encryption as well as private key encryption;
- `config.s2kArgon2Params` (defaulting to "uniformly safe settings" from Argon
RFC): parameters to use on encryption when `config.s2kType` is set to
`enums.s2k.argon2`;

Compared to v5 keys, v6 keys contain additional length fields to aid in
parsing the key, but omit the secret key material length field.

Additionally, unencrypted v6 secret key packets don't include the count
of the optional fields, as per the updated crypto refresh. Since they
are always absent, the count is not needed.

Compared to v5 signatures, v6 signatures include a salt, and the
subpacket lengths are increased from 2 to 4 bytes.

Store key flags, features and preferences in a direct-key signature
instead of user ID signatures, for V6 keys.

The AEAD Encrypted Data packet has been removed from the draft
in favor of version 2 of the Sym. Encrypted Integrity Protected
Data packet. It also has a new feature flag to match.

This flag has been removed from the draft specification.

Also, set it as the preferred AEAD algorithm.

This subpacket replaces both symmetric algorithm preferences and
AEAD algorithm preferences when AEAD is supported, by providing
sets of preferred symmetric and AEAD algorithm pairs.

We still keep the symmetric algorithm preferences in case AEAD is
not supported.

Chrome's Web Crypto implementation doesn't support it, and it
seems unnecessary to list it when AES-256 is available.

This has been changed in the crypto refresh.

Key flags, expiration time, algorithm preferences, et cetera, are now
read from the direct-key signature instead of the primary User ID
binding signature for v6 keys.

This also requires a direct-key signature to be present for v6 keys.

The crypto refresh says that we MUST NOT reject messages where the
CRC24 checksum is incorrect. So, we remove the check for it.

Also, remove the checksumRequired config.

The latest crypto refresh specifies an HKDF step to be used for
deriving the key to encrypt the session key with.

It also specifies two additional length fields.

Instead of calling getPreferredAlgo('symmetric') and
getPreferredAlgo('aead'), we define and call getPreferredCipherSuite()
to determine the preferred symmetric and AEAD algorithm.

Additionally, we remove isAEADSupported(), instead we return
aeadAlgorithm = 0 from getPreferredCipherSuite() if AEAD is not
supported.

And finally, we define getPreferredCompressionAlgo() to replace
getPreferredAlgo('compression').

Rather than using the config to determine which algorithms to try
to decrypt session keys for, try the algorithm we know the message
was encrypted with.

Rather than padding in the PKESK packet, add padding inside the
public-key algorithms, so that we can later add algorithms without
any padding.

Additionally, simplify the constant-time decryption logic, by always
using the assumed algorithm, rather than doing a constant-time select
based on whether the decrypted algorithm identifier was correct.

The latest version of the crypto refresh (i.e., !313, !314) specifies that
the  "Hash" header is depricated. An implementation that is verifying
a cleartext signed message MUST ignore this header.
Thus, the header check can be removed.
This commit does not change the writing part of cleartext messages.