Adsk Contrib - Implement display and view aliases

[doug-walker]

This PR allows config authors to define aliases for displays and views, similar to aliases on color spaces. This allows display and view names to evolve over time while allowing the earlier names to continue to work in DisplayViewTransforms. In addition, it will now be possible to define aliases that simplify working with command-line tools such as oiiotool to apply DisplayViewTransforms.

This new flexibility in naming should be very useful with the upcoming built-in ACES configs.

For displays, this works by treating the aliases to the display's corresponding display color space as display aliases.

For views, this works by adding an aliases attribute to views.

One design decision was whether to add the aliases to the ViewTransform class, and look for views with a view_transform that use it, or add them to the views themselves. My first implementation added them to the ViewTransform because it's nicer to be able to add things to that standalone class rather than needing to add more getters and setters to the Config class. However, I ultimately decided against that approach because:

• The heuristics for matching the views with a ViewTransform became fairly complex.
• It ruled out allowing aliases for views that just use a colorspace.
• It just seems more straight-forward if the aliases are added directly to the views.

The display alias functionality is off by default and requires config authors to opt-in by adding the new use_display_aliases attribute to their config file. This avoids any unintended consequences related to existing configs that were not designed with this in mind. The new functionality requires the config file version to be at least 2.6 or higher.

While working on this, I wound up noticing and fixing a few bugs involving either aliases or the USE_DISPLAY_NAME token.

If application developers are directly using Config::getDisplayViewColorSpaceName, they will probably need to switch to the new Config::getResolvedDisplayViewColorSpaceName, in order to properly handle configs that use display/view aliases. I will mention that in the release notes.

The majority of the code is unit tests, as I was trying to anticipate all scenarios, though a lot of them are edge cases.

Addresses issues #2337 and #2210.

Assisted by: Claude Code / Sonnet 5.

[remia]

I think display / view aliases will be a useful feature and I already see case where it could help us transition display names more smoothly (though in our case it's almost as if you would want a simple / advanced name for each display depending on the target audience), provided DCCs are updated to use the new API to handle this gracefully. Agree with leaving it off by default for now, as I find it a bit hard to wrap my head around all the potential edge cases / consequences involved.

Some of the edge cases handling are a bit convoluted, which may be just me, but could lead to unexpected resolving so may need extra clarity?

Overall looks good, thank you for addressing the side issues like resolving <USE_DISPLAY_NAME> and adding the display description API.

[doug-walker]

@remia , I agree that the view transform aliases were overly complicated. I reworked it and am much happier with this new approach. For the display aliases, I added a comment to try and explain why I think the current resolution approach is necessary. I will make another commit to update the .rst files further.

[cozdas]

I don't see any showstoppers. I left few comments which are mostly about conventions or clarification of the intended behavior. Couple of typos too.

[doug-walker]

@remia and @cozdas , please review my latest commits, I'd like to get this merged on Tuesday please.

[cozdas]

Perfect! ship it!

[remia]

Looks good to me, thanks for the updates @doug-walker!