Implement config compatibility validation for HDR displays

[doug-walker]

Adds an app-helpers function CheckCompatibility that checks if a config supports a given feature set. For now, it only implements one feature set, which is HDR display support. This is intended to test whether a config implements a minimal set of features needed by applications to work with HDR displays, as managed by operating systems (i.e., as opposed to displays driven directly by an AJA video card, or similar).

The requirements on the config are as follows:

• Must the set cie_xyz_d65_interchange role.
• Must use display color spaces.
• Must set the interop_id and encoding attributes on all display color spaces.
• All views must use a view_transform. (One exception is allowed, which is if the colorspace has isData true.)

With these features, an application may take the result of a DisplayViewTransform and convert it to whatever color space may be necessary to comply with an operating system's (or perhaps more technically, a windowing system's) requirements. For example, if the (display, view) pair produces Rec.2100-PQ but the application needs to convert that to scRGB to pass it to the operating system, it would be able to do that. (In fact, it could combine all of that into a single OCIO transform, if desired.)

The hope is that having these requirements in place will make it easier for config authors to make HDR-ready configs that will work across all applications. This would be an improvement over the current situation where each application may have its own special requirements about what the config contains or how things are named.

Note that the OCIO 2.5 Studio and CG configs for ACES 2.0 already meet these requirements.

I named the one enum for CheckCompatibility as CONFIG_HDR_DISPLAY_SUPPORT_26, where the "26" denotes that these are the requirements as of OCIO 2.6. I'm anticipating that we will add additional requirements around view transforms in the future to allow applications to select the appropriate ones for a given display.

These requirements are meant to serve all situations in which the OS color management cannot be bypassed on the way to the monitor. So I was thinking of naming the enum CONFIG_OS_DISPLAY_SUPPORT_26 instead. I decided to go with "HDR" since that was the focus of the many discussions that led to this feature, but am open to alternate names.

I updated ociocheck to print the results of the compatibility check. The output comes after the validation check. The new -v option may be used to print why a config is not compatible. Here is an excerpt:

(output trimmed ...)

** Validation **
Validation: passed

** Compatibility **
HDR Display Support (2.6): yes

(output trimmed ...)

Implements #2332. Please note that this is envisioned as part of a larger suite of functions related to HDR and OS-managed display support, that will arrive after 2.6.0 once the working group has reached consensus on the remaining topics.

Assisted by: Claude Code / Sonnet 5