`VkSamplerYCbCrConversion` should document that no transfer function is applied

Hi, I've encountered a confusing area of the spec that I believe could use some clarification.

My understanding is that when sampling a YUV semi- or multiplanar texture with a `VkSamplerYCbCrConversion` in a shader, the resulting sampled values are generally the nonlinear `R'`, `G'`, and `B'`. That's because of how YCbCr works; it's an extra encoding step on top of RGB values that were already nonlinearized by some transfer function[^1][^2]. So for example if an sRGB picture is encoded in YCbCr using the BT.709 conversion, the values in the shader will be nonlinear sRGB values.

It's not a big problem for the user to do that step themselves in the shader, but it does fly a bit in the face of intuition, given that sampling sRGB textures always results in linear values - Vulkan does the linearization for the user. Furthermore, even a savvy user might be confused about the fact that they passed in a `ycbcrModel`, such as `VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_709`, but that that only represents the matrix transform, not the transfer function applied to the underlying color values. This is extra confusing since Rec. 709 (the document) specifies both the transfer function and the matrix transform.

The easiest API for users would add a field to `VkSamplerYcbcrConversionCreateInfo` to specify the transfer function - defaulting to linear, obviously, for backwards compatibility - so that shaders can operate only on linear values just like they do with sRGB textures. Failing that, I wonder if this could not be called out a bit more explicitly in the documentation. For example, the following note could be added to the documentation for `ycbcrModel`:

> Note: this refers to the YCbCr conversion into R', G', and B', *not* to the transfer function applied to produce those values, despite the transfer function and the YCbCr conversion often having the same name.

Thanks for reading!

[^1]: The reason for this is historical, as discussed in ITU report [BT.2246-8](https://www.itu.int/pub/R-REP-BT.2246-8-2023): it was easier to dump the nonlinear values out to CRT screens if they were already in the right space.
[^2]: With the exception of the BT.2020-CL conversion, which operates on "constant luminance".