Adds support for post-quantum ML-DSA & ML-KEM algorithms

[prabhu]

Fixes #674

With inspiration from the Node.js PRs and this, this pull request adds three new post-quantum algorithms: "ML-DSA-44", "ML-DSA-65", and "ML-DSA-87" and three new key encapsulation mechanisms: "ML-KEM-512", "ML-KEM-768", "ML-KEM-1024" to better future-proof BOM signature validity. The hypothetical but real threat this addresses is that traditional signatures with RSA/ECDSA may become invalid when quantum computers break them.

Following alternative ideas could be considered:

1. URI-Based references

"algorithm": "urn:nist.gov:fips204:ml-dsa-44" instead of simple upper case enum strings. This however is a significant breaking change to replace all existing identifiers in use.

2. Extend signer definition

Signature object support signer as one of the types. A new type called postQuantumSigner could be created to extend signer to capture additional attributes related to PQ algorithms and also to support a broad range of PQ algorithms.

"properties": {
            "signers": {
              "type": "array",
              "title": "Signature",
              "description": "Unique top level property for Multiple Signatures. (multisignature)",
              "items": {"$ref": "#/definitions/signer"}
            }
          }

3. Enable additional properties

Currently, additional properties are disabled for signer. To increase flexibility, this could be enabled.

This PR proposes a simple enhancement to the enum, key type indicators, and validation, making this feature >= 1.7 only without any possibility for backports.

TBD:

Enhancing CBOM to support the corresponding OID values.

Algorithm	OID
ml-dsa-44	2.16.840.1.101.3.4.3.17
ml-dsa-65	2.16.840.1.101.3.4.3.18
ml-dsa-87	2.16.840.1.101.3.4.3.19
ml-kem-512	2.16.840.1.101.3.4.4.1
ml-kem-768	2.16.840.1.101.3.4.4.2
ml-kem-1024	2.16.840.1.101.3.4.4.3

[bhess]

ML-KEM are KEM (similar to public-key encryption) algorithms and not signature algorithms. Is it on purpose to list them here?

[prabhu]

It's a good question. This was added in the last commit. I am happy to revert this if we can merge based on only the signature algorithms alone.

[jkowalleck]

this PR is based on 1.7-dev branch. the respective changes are not part of CycloneDX spec or it's release cycle.

please create all the needed changes based on master branch and target the PR to it.

[prabhu]

Created #682