[Format-v2] Generate cryptographic materials *inside* MLA, instead of using the user configuration

[commial]

For now, the sensitive cryptographic materials are created when the API user is creating the ArchiveWriterConfig.

For the Encrypt layer, this configuration is used to add recipient.
In order to:

• avoid having this sensitive data in a structure manipulated by the client (and then, maybe copied or leaked in some way)
• prepare a key generation closer than the KEM API, ie. encapsulate and decapsulate, which will be used to provide [Format v2] Consider adding Post-Quantum cryptography with hybrid KEM for the encryption layer #195 . Indeed, encapsulate is the one generating the final key -- it is not passed as an argument

As a result, this PR introduce the following workflow:

                      `ArchiveWriterConfig`  <--> User, add recipients, set the compression level, etc.
                              |
                              v
                      -------------- MLA ---
                              |
                       .to_persistent()
                           /       \
 MLA specifics <= InternalConfig  PersistentConfig => to be stored in the header,
                                                      for futur reloaded by the Reader

A few refactoring are also made, such as removing from the public API to_persistent and enforcing the CSPRNG used to implement the trait CryptoRngCore (it was already, but now it is check at compile time, ensuring some robustness to dependency change)

[commial]

Failing tests are caused by an update to Py-bindings (unrelated to this PR) and the "long" test CI enabling the check_archive_v1 test, which is expected to fail