Color space support

The current text has only this to say regarding color spaces:

> Rendering operations involving composition of submitted layers should be assumed to be internally performed by the runtime in linear color space. Images submitted in sRGB color space must be created using an API-specific sRGB format (e.g. DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, GL_SRGBA, VK_FORMAT_R8G8B8A8_SRGB) to apply automatic sRGB-to-linear conversion when read by the runtime. All other formats will be treated as linear values.

This is ambiguous about *what* linear color space is used to interpret application images, since "linear" defines only a (trivial) transfer function, not a set of primaries. A reasonable reader could infer that linear sRGB is intended, but this should be made explicit.

Furthermore, no mechanism is provided for an application to supply frames in color spaces other than sRGB regardless of transfer function, i.e. color spaces with different RGB primaries. This is needed to support the full output range of future and existing devices, such as the Oculus Quest, which [supports Rec.2020 natively](https://developer.oculus.com/design/oculus-device-specs/) and allows its use through the Oculus SDK.

Vulkan presents useful prior art for how such an interface might be defined. In particular, applications can query supported color spaces for a given surface with [`vkGetPhysicalDeviceSurfaceFormats2KHR`](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#vkGetPhysicalDeviceSurfaceFormats2KHR) and select a desired one when [constructing a swapchain](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_wsi_swapchain). [`VkColorSpaceKHR`](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VkColorSpaceKHR) as extended by [`VK_EXT_swapchain_colorspace`](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_swapchain_colorspace) defines a reasonable set of possible color spaces. An implementation which advertises support for a color space on some surface guarantees that it can display images in that color space, either natively or by applying a transform, e.g. to correctly display sRGB images in a wider-gamut display.

It might be desirable to mandate support for some color spaces. Subject to the ambiguity described above, support for nonlinear sRGB is probably de facto mandatory as an OpenXR runtime must be well behaved when operating in un-extended 1.0 mode. A pass-through color space is also useful for applications which can determine characteristics of the device via a side channel such as platform-specific APIs or hardcoded knowledge of a specific device, where such characteristics do not necessarily correspond exactly to one of the standard color spaces. This is particularly desirable as it exposes the full capabilities of unforeseen future displays.

No source file or test is named. Start with the current color-space wording quoted in the issue, then compare the Vulkan surface-format and VkColorSpaceKHR references linked there. Done means the specification explicitly defines the linear color space and settles how applications select or provide other color spaces, including support guarantees.

Written by the indexing model from the issue text.