Color Interop ID

# Open Effects Proposal for Standard Change

Please read the contribution [guidelines](https://github.com/AcademySoftwareFoundation/openfx/blob/main/CONTRIBUTING.md) first.

## Standard Change Workflow
- [x] Create proposal as issue (you're doing this now!)
- [x] Tag this issue with `standard change` tag
- [ ] Identify subcommittee: at least one plug-in vendor, and at least one host
- [ ] Discuss the idea in this issue
- [ ] Write new or updated code and doc
- [ ] Publish updates as a pull request (ideally on a `feature/PROPOSAL-NAME` branch)
- [ ] Make sure that PR references this issue number to keep them in sync
- [ ] Discuss and review code in the PR
- [ ] Meet all requirements below for accepting PR
- [ ] When subcommittee signs off and other members don't have any further review comments,
maintainer merges PR to main which closes PR and issue

## Requirements for accepting a standard change:
- [ ] Header files updated
- [ ] Documentation updated
- [ ] Release notes added
- [ ] Compatibility review completed
- [ ] Working code demonstrated with at least one host and one plugin
- [ ] At least two members sign off
- [ ] No further changes requested from membership

## Summary

The Color Interop Forum has defined a set of scene and display colourspaces, and a namespacing mechanism, with the aim of standardising machine-readable names for colourspaces across the industry. OpenFX should revise its colour management API to be compatible with this.

## Motivation

At the moment, colourspace definitions in OpenFX are linked to the OCIO ACES Studio config. While this is a widely used specification, it is tied to a specific implementation and not truly vendor neutral. Color Interop ID addresses this, and is being adopted across other ASWF projects as the standard way to encode colourspace names, interoperating between systems that do and don't use OCIO.

## Problem

Currently to go beyond the basic colour management style requires either using OCIO or implementing a large set of ACES colourspaces in a different system. This is a burden for plug-in and host writers who would like well-defined colour but lack an ACES-compliant implementation.

## Impact

This would be added as either a new version of the colourspace properties, or a new style. Either approach is backwards compatible, so the new functionality will be opt-in.

## Documentation Impact

Basic info on Color Interop ID and the set of new property values will need to be documented.

## Stakeholders

Hosts and plug-ins that do not use OCIO or ACES will be the main beneficiary of this proposal.

## Discussion

There is no concrete implementation proposal yet, this issue is a placeholder.