Introduce pre-defined perspectives

[taleodor]

Implements #1066.

What this adds
1. Schema: optional predefined field on perspective (cyclonedx-perspective-2.0.schema.json)

{
  "perspectives": [
    { "predefined": "model-card" }
  ]
}

• Identifies predefined (well-known) perspectives published in the CycloneDX perspectives catalog and incorporates the published definition by reference, giving tooling stable spec-backed identity instead of free-text name matching.
• predefined and inline mappings are mutually exclusive (oneOf, enforced in both directions): a perspective either declares a pre-defined identity or defines its own mappings, never both. The part-of-spec published definition is the single source of truth for what a pre-defined perspective contains.
• Initial enum values: model-card, pqc-readiness (the latter matching the catalog entry proposed in Add sample PQC readiness perspective for CBOM #960), with meta:enum descriptions.
• Naming follows the schema's existing preDefinedPerspectiveDomain vocabulary.

Why a field rather than the choice pattern
We deliberately chose a field on the perspective object instead, since it keeps a pre-defined perspective addressable. A bare enum string cannot carry a bom-ref, so a string-item pre-defined perspective could never be the target of a BOM-Link or any other intra-document reference. With the field form, { "bom-ref": "…", "predefined": "model-card" } remains a first-class, referenceable node, and the oneOf on the object enforces the same pre-defined/custom exclusivity the choice pattern would have given us.

2. Catalog: perspectives/model-card-perspective.json

Second entry in the perspectives/ catalog introduced by #960, following its delivery shape (a complete, minimal, valid 2.0 document containing only the perspective). This is the definition incorporated when a document declares "predefined": "model-card".

The mappings express the industry-standard model card structure over the 2.0 decomposition of the former first-class modelCard entity:

• intrinsic technical characteristics via modelProperties, scoped to $.components[?(@.type=='machine-learning-model')] (the only component type that may carry them)
• training datasets as components of type data
• supplier / intended users via the party model roles
• intended use cases as use case definitions
• ethical and fairness considerations as risk model entries (ethical domain; fairness/bias impact categories)

3. Test fixtures (auto-discovered by the schema-v2 suite):

• valid document covering the reference form and a plain inline perspective; invalid documents covering an unknown predefined value and the forbidden mixed form (predefined + mappings).

Not included

• Bundled schemas — left to the post-merge bundle workflow, per repo convention.
• Conformance validation — the schema validates identity and exclusivity; whether a document's data satisfies a perspective's mappings remains tooling territory, as for perspectives generally.

Dependencies

• Premised on Clean check-in of AI/ML. Supersedes #948.  #990: the catalog entry's mappings target modelProperties. The schema change and fixtures stand alone; only the catalog entry's JSONPath expressions assume Clean check-in of AI/ML. Supersedes #948.  #990's shape. Happy to rebase/adjust if that lands differently.
• Complements Add sample PQC readiness perspective for CBOM #960: adopts its perspectives/ folder and delivery shape, and reserves pqc-readiness for its entry.