feat(color): Add srgb_rec709_display as a built-in color space

[brechtvl]

Description

srgb_rec709_display is now a built-in color space alongside srgb_rec709_scene, and config color spaces like "sRGB - Display" are now classified as such. The built-in sRGB name remains an alias of srgb_rec709_scene.

This means it can be relied on to be available, even when using an OCIO config that does not contain it. And it is on equal footing with srgb_rec709_scene in case it becomes the default in the future.

Tests

Added some tests to detect the presence of this.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
  line in the pull request description above.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested in the testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[brechtvl]

CC @zachlewis

This is the last of my own changes I currently hope to get into 3.2, to make the display interop ID support somewhat complete. In the sense that when it's encountered from e.g. a user input or colorInteropID it should work equally well as the corresponding scene referred interop ID, but without yet making it the default guess when reading files.

[lgritz]

After I merged #5391, this needs to be rebased and have any conflicts resolved.

[lgritz]

@zachlewis This look ok to you before I merge it?

[zachlewis]

Yes, absolutely!

tl;dr -- this is great, thank you Brecht! I don't totally agree with "sRGB" as an alias for srgb_rec709_scene per say, but for the sake of keeping things simple, we can keep it for now, and we can further discuss in a separate rfc.

Internally, I would like to conform the rest of the codebase to using CIID strings; and we can discuss mechanisms for deferring the interpretation of srgb_rec709_display as srgb_rec709_scene instead, or vice versa, as part of a "resolution policy" which affects the way ColorConfig::resolve behaves.

I also think we should maybe create a new IBA for converting to the scene_linear role that takes either a colorimetric or inverse-display-view path to scene_linear depending on what the input color space is. Close to what the inverse display-view transform does by default, but with special handling for scene-referred input spaces that should just use colorconvert for the transform instead. Does this sound about right for your use cases, Brecht, and would it be helpful to you if we wrapped up the handling logic in a single IBA?

[lgritz]

LGTM

[brechtvl]

I also think we should maybe create a new IBA for converting to the scene_linear role that takes either a colorimetric or inverse-display-view path to scene_linear depending on what the input color space is. Close to what the inverse display-view transform does by default, but with special handling for scene-referred input spaces that should just use colorconvert for the transform instead. Does this sound about right for your use cases, Brecht, and would it be helpful to you if we wrapped up the handling logic in a single IBA?

I think ImageBufAlgo::colorconvert already does something different for scene and display spaces when needed, because OpenColorIO colorspace transforms automatically go through the default_view_transform as needed. And there is also ImageBufAlgo::ociodisplay with inverse=true.

It's not clear to me what the new IBA would do.