Let a control import assessment requirements from another catalog instead of restating them #492

Problem

Imported controls have no mechanism for attachment to new objectives in the importing catalog.

Concrete case, from a WIP adopter-side catalog built on the OSPS Baseline. The top of the file carries 27 imports entries like:

imports:
  - reference-id: osps-baseline
    entries:
      - reference-id: OSPS-VM-02.01
        remarks: "OSCA-SP-01.01 confirms published security contacts so the adopter can report what it finds."
      - reference-id: OSPS-VM-03.01
        remarks: "OSCA-SP-01.01 confirms a private reporting channel so reports do not become public before a fix exists."

and 300 lines later the control those two can only be associated to a control objective with something like this:

  - id: OSCA-SP-01
    objective: |
      Ensure the adopter and outside researchers can report vulnerabilities to
      the project privately and that the project has committed to respond.
    assessment-requirements:
      - id: OSCA-SP-01.01
        text: |
          The adopter MUST confirm that the project publishes security
          contacts and a means to report vulnerabilities privately.
        recommendation: |
          This is OSPS-VM-02.01 and OSPS-VM-03.01. ...

Proposal

1. Let AssessmentRequirement carry exactly one (XOR) of text (inline) or source (an EntryMapping to a requirement in an external catalog).
2. Use the documentation to encourage users to import full controls at the top level when needed, but discourage importing of assessment requirements directly.

We should also document recommendations for ingestion on a few points:

• Whether a control-level import replaces the per-requirement source or complements it.
• Whether applicability on an imported requirement is set locally (it is scoped to this catalog's applicability groups, so probably yes).
• Whether the existing catalog-level imports: block still has a role once the link is expressed at the point of use.