DisplayViewTransform should fall back to display color space aliases

Currently, OCIO displays do not have aliases. This makes it difficult to change the name of a display in a config without breaking backwards compatibility (and using the inactive list is not ideal). Regular color spaces, including display color spaces already have this feature via the aliases attribute of the color space.

For displays that use views that define their display_colorspace as `` (which is most views in modern config files), I propose that if a DisplayViewTransform is unable to find the requested display that it fall back to looking at the aliases for all display color spaces.

One possible unintended consequence is that it would potentially allow some DisplayViewTransforms that legitimately should have failed to now succeed. I'm unable to think of a likely example of where that would be a problem, but we could potentially add a config-level attribute such as `allow_display_aliases: true` to require config authors to opt-in to the behavior.

Similar to the display scenario, I propose that if a DisplayViewTransform is unable to find the view, that it search in a new aliases attribute of the ViewTransforms.

Start by tracing how DisplayViewTransform resolves displays and views, then compare that behavior with the existing aliases attribute on regular color spaces. Review how display_colorspace set to is handled in modern config files. Done means an agreed, tested behavior for display and ViewTransform aliases, including whether config authors must opt in.

Written by the indexing model from the issue text.