Add configurable RFC 7093 subject key identifiers

[nokitoino]

Summary

• add Subject_Key_ID_Method with explicit choices for RFC 5280
  section 4.2.1.2 method 1 and RFC 7093 section 2 methods 1, 2, and 3
• add a Subject_Key_ID(const Public_Key&, Subject_Key_ID_Method)
  constructor
• expose the same explicit selection through X509_CA::choose_extensions(),
  both X509_CA::sign_request() variants, and
  X509::create_self_signed_cert()
• keep the existing RFC 5280/SHA-1 behavior as the default for every
  existing call
• test the SHA-256 implementation against RFC 7093 section 3's published
  P-256 vector, and cover SHA-1, SHA-384, SHA-512, invalid input, CA-issued
  certificates, and self-signed certificates

RFC 5280 method 1 hashes the value of the subjectPublicKey BIT STRING
with SHA-1 and produces 20 bytes. RFC 7093 methods 1, 2, and 3 hash the
same BIT STRING value with SHA-256, SHA-384, or SHA-512 and retain the
leftmost 160 bits.

The certificate signature hash and the SKI derivation method remain
independent. For example, a certificate may be signed with SHA-256 while
retaining the existing RFC 5280/SHA-1 SKI default, or it may explicitly
request an RFC 7093/SHA-256 SKI.

AKI handling is unchanged. A CA-issued certificate continues to copy the
issuer certificate's SKI byte-for-byte into its AKI. A self-signed
certificate uses its newly derived SKI as its AKI.

Compatibility

This change is additive. Existing source calls retain their signatures and
behavior:

• Subject_Key_ID(const Public_Key&) still uses RFC 5280 method 1
• existing X509_CA::sign_request() overloads still use RFC 5280 method 1
• the existing X509_CA::choose_extensions() overload still uses RFC 5280
  method 1
• the existing X509::create_self_signed_cert() overload still uses RFC
  5280 method 1
• the deprecated byte-vector/hash-name constructor and the deprecated
  choose_extensions() compatibility overload remain available and
  unchanged

Consequently, RFC 7093 output is produced only when a caller uses a new
overload and explicitly selects an RFC 7093 enum value.

The automatic SHA-1 behavior was introduced independently by #5735. Before
#5735, automatic certificate generation used the certificate signature hash
over the DER-encoded SubjectPublicKeyInfo and truncated digests longer than
24 bytes. Thus, upgrading across #5735 can change SKI values without a caller
changing its source code. This PR does not introduce another implicit
behavior change; it preserves #5735's default and adds an explicit opt-in.

RFC 7093 method 4 is deliberately out of scope. It hashes the DER-encoded
SubjectPublicKeyInfo rather than the subjectPublicKey BIT STRING and does
not prescribe the same fixed 160-bit result as methods 1 through 3.

Related: #3479 and #5735

Testing

• make -j4 tests
• env LD_LIBRARY_PATH=. ./botan-test x509_unit
  • 1,841 tests passed
  • X509 subject key id derivation: 9 tests passed
  • X509 Unit: 339 tests passed
• minimized static build with x509, ECDSA/P-256, RSA, SHA-1, and SHA-256,
  but without the sha2_64 module
  • x509_unit: 658 tests passed
• python3 src/scripts/ci_check_headers.py build/build_config.json
• python3 src/scripts/ci_check_generated_files.py --base upstream/master
• make docs
• git diff --check

Disclosure

This patch was developed with GPT-5.6. Sol.

[randombit]

TBH was unaware of this RFC.

Extension changes look fine on first glance.

Revert all of the issuance changes (sign_request, choose_extensions, etc) - I'm planning on a whole new cert issuance flow [for 3.14] and this feature can get handled there, adding it to the old APIs seems like pointless churn esp for a feature that seem relatively marginal.

[randombit]

This constructor is anyway new (not yet in any release) so could change it now to always take a Subject_Key_ID_Method and default to SHA-1