Bind ViewDefinition operations to their own output format ValueSets

[johngrimes]

The $viewdefinition-run and $viewdefinition-export operations currently bind their _format parameter to the shared OutputFormatCodes ValueSet, which includes all codes from the CodeSystem (including fhir).

The fhir format returns a FHIR Parameters resource and is currently only defined for $sqlquery-run. The ViewDefinition operations return Binary or bulk export files, and the spec does not define fhir format behaviour for them.

PR #327 introduced a dedicated SQLQueryRunOutputFormatCodes ValueSet for $sqlquery-run. The same approach should be applied to the ViewDefinition operations:

• Create a ViewDefinitionRunOutputFormatCodes ValueSet containing csv, ndjson, parquet, and json.
• Create a ViewDefinitionExportOutputFormatCodes ValueSet containing csv, ndjson, parquet, and json.
• Update the _format parameter bindings in both operations to reference their respective ValueSets.

If support for a FHIR output format is added to either ViewDefinition operation in the future, the respective ValueSet can be updated as an independent change.

This was deferred from #327 as it affects operations outside that PR's scope.

[niquola]

Why do not support fhir for $viewdefintion-run? (not sure it has any meaning for $viewdefintion-export?)

[johngrimes]

I agree that we could - perhaps this should be a separate issue.

[johngrimes]

Closing as resolved by #365 (with #327 as background).

We went the opposite way to this issue's premise: fhir is now intentionally supported for $viewdefinition-run, not excluded. Rather than per-operation ValueSets, _format is split by operation kind - OutputFormatCodes (includes fhir) for the run operations and ExportOutputFormatCodes (excludes fhir) for the export operations. Since the two run operations share format semantics (and likewise the two exports), separate ViewDefinition ValueSets would add nothing. The export operations already exclude fhir, which was the substantive concern here.