Make certain color space names reserved

One of the agreed upon requirements for the nanoColor project is that there be a set of color space names which are guaranteed to always mean the same thing. Applications must be able to rely on these as fixed and which have not been redefined by the config author.

One of the core tenets of OCIO is to give config authors complete control over the color processing, so the names must be carefully chosen so that they are unlikely to overlap with names already in use in typical configs. This was one of the considerations that was used when choosing the names below.

One question is whether this will apply only to the nanoColor version of the library or to both nanoColor and full OCIO. The proposal here is that it will apply to all versions.

Another question is what it means for a color space to be constant. Given that the reference space may be changed, any color spaces built against an original reference space would need to be updated accordingly. Thus it's not as simply as just checking the cacheID or serialized version of the color space transform components. One solution would be to convert a color space to use a specific reference space and then evaluate certain RGB values and check that they are within a tolerance.

The proposal for how the rule would be enforced is similar to how version consistency checks are already done as part of validation. Namely, if a color space uses one of the reserved names, as either the main name or an alias, it would be evaluated as described in the preceding paragraph to ensure that it is a valid implementation. If not, the config would fail validation. The reserved names would not be allowed as role names or Named Transforms.

This check would only apply to config versions greater than or equal to the current version number when this feature is implemented.

Note that for applications that care about this feature, they will need to call validate() on the config before using it. However, that is always the recommended practice regardless of this feature, so should not be a burden.

Here are the list of reserved names, these are from the ASWF Color Interop Forum recommendation for ["Color Space Encodings for Texture Assets and CG Rendering"](https://docs.google.com/document/d/1IV3e_9gpTOS_EFYRv2YGDuhExa4wTaPYHW1HyV36qUU/edit?usp=sharing):
- lin_ap1_scene
- lin_ap0_scene
- lin_rec709_scene
- lin_displayp3_scene
- lin_rec2020_scene
- lin_adobergb_scene
- lin_ciexyzd65_scene
- srgb_rec709_scene
- g22_rec709_scene
- g18_rec709_scene
- srgb_ap1_scene
- g22_ap1_scene
- srgb_displayp3_scene
- g22_adobergb_scene

In addition, if "data" exists as a color space, its isdata property must be "true". If it exists as a role, it must point to a color space that meets the same requirement. It may not be used as a NamedTransform.

Start by reviewing the existing version-consistency checks used during config validation and the validate() path. Determine how reserved color-space names, aliases, roles, Named Transforms, reference-space changes, and the data color space should be checked for supported config versions. Done means the proposal's validation rules are defined and covered for both nanoColor and full OCIO.

Written by the indexing model from the issue text.