CycloneDX 2.0 - Constrain Properties to Applicable Types

### Problem

In CycloneDX 1.x, several properties are loosely defined and may appear on types where they are semantically invalid. For example:

- `cryptoProperties` is intended only for cryptographic assets (e.g. cryptographic libraries, keys, algorithms), but is currently allowed on any `component`.
- `modelCard`, `evaluationMeasures`, and other AI/ML-specific metadata may appear on non-AI components.

This flexibility was useful during schema evolution, but introduces:
- Semantic ambiguity
- Inconsistent SBOM usage
- Misleading tool or ecosystem behavior

---

### Goal for 2.0

Enforce **contextual constraints** on properties by:
- Restricting `cryptoProperties` to cryptographic asset types (e.g. `library`, `firmware`, `machine-learning-model`, etc.)
- Limiting AI/ML-specific fields (`modelCard`, `evaluationMeasures`, `datasets`, etc.) to components of `type: machine-learning-model`
- This ticket is not limited to `cryptoProperties` or `modelCard` and may be applicable to other properties in v1.6 or which will be introduced in v1.7.

---

### Proposal

Update the CycloneDX 2.0 schema to:
1. Apply `oneOf` or `if/then/else` constraints where schema logic permits
2. Scope optional fields to valid `component.type` or `service.category` values

---

As written, this is not a breaking change and the documentation in the current specification clearly states the purpose and when to use these properties. This ticket is for the enforcement of that behavior through minor changes in schema structure.