Add kOfxParamPropColourManagement for colour-managed RGB/RGBA params (#158)

[garyo]

Implements the agreed spec change from #158. Companion to #244 (the contrib/colour conversion library).

What

Adds kOfxParamPropColourManagement, a string-enum parameter property a plug-in sets on an RGB or RGBA parameter to declare the colourspace of the parameter's values — defaults, current value and keyframes alike:

• kOfxParamColourManagementNone — legacy, unmanaged (the default; existing plug-ins are unaffected).
• kOfxParamColourManagementManaged — ACES2065-1 (AP0) reference colourspace; scene-linear, not clamped to [0..1]. For colours that participate in image processing (key colour, solid fill, etc.).
• kOfxParamColourManagementSRGB — sRGB ("web" RGB), clamped to [0..1]. For display-referred UI colours such as Draw Suite overlays; not for processing image pixels.

This replaces the earlier boolean kOfxParamPropColourManaged with the three-state design the #158 discussion converged on (a managed/scene-linear mode and an sRGB mode for overlay/UI colours). The encoding is fixed at parameter-definition time and is fully specified without an OCIO config, so colour-managed and unmanaged hosts alike can support it.

Rules (see the spec text for the full musts/shoulds)

• A plug-in must set the property only at parameter-definition time, must check the set status (and fall back to None if unsupported), and must supply/interpret all values in the declared space.
• A host that supports it must accept all three values, should convert the colour into whatever space it needs, and should store managed/sRGB values as ACES2065-1/sRGB in project files for portability.

Changes

• include/ofxParam.h: the property and its three values with @propdef metadata (enum, dim 1), plus new ParamsRGB/ParamsRGBA property sets (the colour param types were not previously modelled in the metadata system).
• Documentation/sources/Reference/ofxParameter.rst: spec text in the Colour Parameters section.
• Examples/Rectangle/rectangle.cpp: declares its solid-fill colour param as Managed, demonstrating the mandatory set-status check.
• release-notes.md: noted under 1.5.1.
• openfx-cpp/include/openfx/*: regenerated metadata, property sets and typed accessors via scripts/gen-props.py.

Validation

• scripts/gen-props.py passes all checks and is idempotent.
• The property resolves to enum / dimension 1 with the three values consistently across the generated metadata and accessors (ParamsRGB::setColourManagement(...) etc.).
• The Rectangle example compiles cleanly.

🤖 Generated with Claude Code

[revisionfx]

A documentation note was host should save such parameter value(s) in project file in ACES2065-1 so as we increase interoperability between apps, this stays robust. And to be clear if this property is supported, plugin is expected to create default values in ACES2065-1.

Of course hard to test right now :)

[garyo]

Thanks for the note, Pierre — added that now (both header and doc). And I note that you can test the colour-conversion lib any time; that's totally standalone, usable by any host or plug-in.

[Guido-assim]

Does it matter how a host stores the value internally? As a host I also need to store the actual color space (and maybe RGB values) to have the color control show up the same. I can understand that if you have some file format to interchange data between different applications that you want to include the ACES value.

[garyo]

It's a reasonable question. I personally think that as long as any export/import goes via the approved space, and the value will be properly back/forward compatible and cut/paste, scripting and things like that work as expected, then nobody will know or care how you actually store it. @revisionfx?

[fxtech]

@garyo looks like some of your Property Set stuff got into that commit. Can you clean up the PR commits and we'll take a look at it?