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 treating the name and aliases of the view's view_transform as aliases to the view. ViewTransforms did not already have aliases, so this PR adds those as well.

One design decision was to add the aliases to the ViewTransform class rather than the views themselves. There were a number of reasons for this choice, including:

• There is no class for views, so it would require adding at least six more functions to the already long Config class.
• This is consistent with how we handled the addition of interchange attributes, and is likely how we would handle any additional view-related functionality.

This functionality is off by default and requires config authors to opt-in by adding the new use_display_view_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.