feat(cryptography): add cryptographic agility plane to CBOM

[bhess]

Summary

This adds the cryptographic "agility plane" outlined in #892. It records how a cryptographic asset's configuration was set, how that configuration can be changed, and how keys and certificates are rotated and renewed, so that crypto-agility and PQC migration readiness can be expressed in a CBOM.

This covers the three observable dimensions raised in the issue: configuration source, change mechanism, and rotation/renewal. Everything is optional, so existing CBOMs stay valid.

What's added

A new cryptoProperties.agility object that applies to any asset type:

• configurationSource: how the configuration was determined, roughly ordered from least to most agile: hardcoded, product-default, administrator-configured, policy-managed, negotiated (plus other, unknown).
• configurationRef: a bom-ref to the configuration that drives this setting, typically a data component whose data type is configuration.
• changeMechanism: how a change gets applied, ordered from least to most agile: not-possible, hardware-replacement, firmware-update, software-update, restart-required, runtime-config (plus other, unknown).

A shared lifecycleAutomation enum for the degree of automation, ordered from least to most agile: not-supported, manual, on-demand, automatic (plus other, unknown).

Two per-domain lifecycle objects:

• certificateProperties.renewal = { automation, mechanism }, where automation is a lifecycleAutomation value and mechanism is a free-form string (e.g. ACME, EST, SCEP, CMP, CMC).
• relatedCryptoMaterialProperties.rotation = { automation, mechanism }, where mechanism is a free-form string (e.g. KMIP, PKCS#11, AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault Transit).

Design notes

• The degree enums are ordered (roughly) from least to most agile so values can be compared; other and unknown follow the usual CycloneDX convention.
• The lifecycle mechanism fields are free-form strings with examples rather than enums, since rotation mechanisms in particular vary a lot (protocols, interfaces, managed services). The name follows the existing securedBy.mechanism.
• configurationSource and changeMechanism live on one agility object instead of being repeated per asset type, because they apply equally to algorithms, protocols, certificates, and keys.

Other agility aspects

• The "ownership" will likely tie in nicely with the new actor/role model being developed for 2.0.
• The "roadmap" may be covered by the mitigation support in the "risk" schema.

Will need to investigate both approaches to ensure that they will meet the intended use cases described in this ticket. The "ownership" feature is currently further along.

Originally posted by @stevespringett in #892

Backwards compatibility

Fully additive; no breaking changes.

Refs #892