Add cohort scripting commands: ExportCohortAsScript / BuildCohortFromScript

[mtinti]

Proposed Change

Adds two CLI commands under CommandExecution/AtomicCommands/CohortScript:

• ExportCohortAsScript — decompiles a CohortIdentificationConfiguration into a portable,
  data-free folder: requirement.md (placeholder), build.script.yaml (a runnable command
  script that recreates the cohort), query.sql (the SQL RDMP would run; if the cohort cannot be expressed as one query - sets span servers/credentials with no QueryCache - this falls back to a best-effort per-set decomposition plus notes) and
  catalogue-manifest.yaml (the extractable columns, patient-identifier column(s) and published
  filters of only the catalogues this cohort uses). The build script captures set operations,
  nested cohort sub-containers + child order, published-filter imports with parameters,
  hand-written filters, global (cohort-level) and aggregate-level parameters, nested AND/OR filter
  containers, patient index tables (joinables) with their joins/filters/parameters + the ix####
  alias, forced joins, disabled sets and sub-containers, customised dimension SQL, and the Project
  association. No patient data is emitted — only catalogue/table/column names and filter logic.
• BuildCohortFromScript — the inverse: replays a build.script.yaml to rebuild an identical cohort.

The captured set was cross-checked against RDMP's native "clone Cohort Identification Configuration"
cascade so that an export → file → rebuild reproduces the same object graph the clone would, for
every aspect that affects cohort membership.

Notes for reviewers: CLI-only — the commands also appear in the GUI "Run…" palette automatically,
but there's no right-click wiring in this PR. No database migration; metadata only (no data processing).
A CHANGELOG entry will be added before this leaves draft.

The query.sql cross-server fallback is verified with a two-server docker fixture: the real "different server ... no QueryCache" error is captured, each set's SQL is emitted individually and executes against its own server, while a single-server cohort still produces the real combined query.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that would cause existing functionality to not work as expected)
• Documentation-Only Update
• Other (if none of the other choices apply)

Checklist

• Ensured that the PR branch is in sync with the target branch (i.e. it is automatically merge-able)
• Created or updated any tests if relevant
• Have validated this change against the Test Plan
• Requested a review by one of the repository maintainers
• Have written new documentation or updated existing documentation to detail any new or updated functionality and how to use it
• Have added an entry into the changelog