This is a collection of potential API improvements found in #3609.

• Parameter consistency for generic key handling functions (pk_algs.h)
  The generic function create_private_key() takes string-typed algo_name and algo_params to identify the algorithm (see also Type-based algorithm instantation  #3275). In contrast load_{public/private}_key() requires an AlgorithmIdentifier object. This is inconvenient, as it requires the user to find a way to translate between the two.
• New method: Public_Key::raw_public_key_bits()
  (Introduce Public_Key::raw_public_key_bits() #3985)
  Currently, we provide public_key_bits() ("BER encoded public key bits") and subject_public_key() ("X.509 subject key encoding"). Especially the new PQC algorithms seem to converge on their own (concat-based) encodings. Key agreement public keys could make this an alias for PK_Key_Agreement_Key::public_value(). Other keys might treat raw_public_key_bits() as an alias for the existing public_key_bits().
• New method: std::unique_ptr<Private_Key> Public_Key::generate_another(RNG&)
  (Feature: AsymmetricKey::generate_another() #3770)
  ... to generically generate an equivalent new key pair with the same algorithm (and configuration) as the public key at hand. Use case: Mapping a KEM interface using a Key Agreement algorithm. The abstract "Encaps()" function needs ::generate_another() to conveniently create an ephemeral keypair without knowledge about the exact underlying algorithm.
• New method: std::optional<uint64_t> Private_Key::remaining_operations() const
  (Add Private_Key::remaining_operations() #3821)
  LMS and XMSS both have stateful operation, but there is no generic way to detect how many operations remain on a key. The proposed method should return nullopt for non-stateful algorithms, otherwise the remaining number of valid usages. [1]
• (to be discussed) Internal static access to algorithm parameters
  Allow accessing algorithm parameters (such as "shared key length", ...) statically. This would simplify some internal implementations that statically know which algorithm they are going to deal with. That might be useful not just for asym algos but in general (1, 2). For instance to avoid magic number such as: Feature: x448 and Ed448 #3933 (comment)