Kafkacrypto

This release adds initial NIST FIPS post quantum support, by adding a new key exchange type based on a Curve25519+ML-KEM-1024 hybrid, and a new signature type based on a Ed25519+SLH-DSA-SHAKE-128f hybrid. This also includes a new public controller test, to ensure pq signing works in all operating modes.

See associated pull requests, 3, 4, 5, for details.

Compatibility Notes
1. Adding full pq support required a change to the `CryptoKey` API, so alternative implementations will need to be modified to support the additional functions required for multi-signature chain support: `limit_spk, get_id_spk, get_num_spk`.
2. The CryptoKey API changes mean that once updated to this version, you cannot roll back to older versions without manually downgrading the file storage format for the file-backed CryptoKey (if used), and without moving the entry in the KafkaCryptoConfig file from the new `chains` section back to its original location.
3. There should be full compatibility between producers/consumers/controllers/chain-servers running different versions, but of course key exchange is only possible if they share at least one signature and one key exchange type.

This release adds initial NIST FIPS post quantum support, by adding a new key exchange type based on a Curve25519+ML-KEM-1024 hybrid, and a new signature type based on a Ed25519+SLH-DSA-SHAKE-128f hybrid. This also includes a new public controller test, to ensure pq signing works in all operating modes.

See associated pull requests, 3, 4, 5, for details.

Compatibility Notes
1. Adding full pq support required a change to the `CryptoKey` API, so alternative implementations will need to be modified to support the additional functions required for multi-signature chain support: `limit_spk, get_id_spk, get_num_spk`.
2. This is a pre-release.
3. The CryptoKey API changes mean that once updated to this version, you cannot roll back to older versions without manually downgrading the file storage format for the file-backed CryptoKey (if used), and without moving the entry in the KafkaCryptoConfig file from the new `chains` section back to its original location.

This release includes two changes:

1. Fully separate dependencies on kafka backends, so that only a single backend (either [kafka-python](https://github.com/dpkp/kafka-python) or [confluent-kafka](https://github.com/confluentinc/confluent-kafka-python)) is needed for functionality. This means [kafka-python](https://github.com/dpkp/kafka-python) has been dropped as a hard dependency and instead there are two optional dependencies: kafkacrypto[kafka-python] (to install the kafka-python backend with kafkacrypto) or kafkacrypto[confluent-kafka] (to install the confluent-kafka backend with kafkacrypto). If neither of these optional variants is selected, kafkacrypto will use whichever backend is currently installed. This change enables full support of Python 3.12.
2. Add an optional tunable controlling whether KafkaCryptoStore sets the configuration of all loggers, or just those for the kafkacrypto package.

This release adds the ability for users to determine whether a ciphertext will ever be decryptable (if keys become available). This helps downstream projects, such as [OpenMSIStream](https://github.com/openmsi/openmsistream) handle that case with a better user experience.

This adds a public round trip test, and fixes two bugs:
1. A bug in KafkaCrypto that would cause producer subscriptions to not be properly updated in all instances.
2. A bug in store_opaque value which had the order of arguments reversed.

This release fixes one security issue, updates logging, and adds support for post quantum secure key exchange. Specific changes:

1. Converted various exceptions to info messages to reduce clutter in logs and provide more informative detail.
2. Add construction and printing of a code version hash.
3. Add key exchange versioning. This changes the on-the-wire format, and is presently done in a backwards-compatible way through the legacy tunable.
4. Add support for the post quantum secure hybrid key exchange algorithm Curve25519+sntrup761. This pairing was chosen because sntrup761 was not selected as a candidate for standardization by NIST, so is not likely to see further tweaks, and is independently implemented already in OpenSSH to provide pq security. Right now this requires manual installation of liboqs-python and changing a tunable to enable.
5. Fix a security issue where a malicious, active, MITM with a valid signing key could replace a key request random value with their own. It is not obviously exploitable beyond making denial of service easier. Controllers (if used) must be updated first.

As a consequence of the security fix, controllers must be updated first so that they no longer replace the random value with their own.