rephrase SPIR-V "Data Format for Reading and Writing Images"

from a SYCL discussion: https://github.com/intel/llvm/issues/21366#issuecomment-3967521156

I think we should consider rephrasing the requirements in the OpenCL SPIR-V environment spec in the [Data Format for Reading and Writing Images](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_data_format_for_reading_and_writing_images) section to enable additional static SPIR-V validation.

Specifically, I think we should tie vector vs. scalar data to the Depth operand in the OpTypeImage, which is testable and known at compile time, instead of the Image Channel Order, which is only known at runtime. Strictly speaking, this is tightening some requirements, but I believe all SPIR-V generators are adhering to these requirements in practice, and all SPIR-V consumers are assuming these requirements are present.

The changes I propose are:

1. Add two requirements to [Section 2.5.2 - Image-Related Data Types](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_data_format_for_reading_and_writing_images):
* Behavior is undefined if an OpTypeImage with Depth = 0 has a Depth or DepthStencil image channel order.
* Behavior is undefined if an OpTypeImage with Depth = 1 does NOT have a Depth or DepthStencil image channel order.
* We can figure out the exact way to phrase these requirements, but informally, this means that a compiler and the validator can look at the Depth operand to determine whether or not the image is a depth image.
2. Given (1), we can therefore:
* Update Table 11 _Mapping Image Data to Vector Components_ to say that the data must be a four-component vector type when Depth = 0.
* Update Table 12 _Scalar Image Data_ to say that the data must be a scalar type when Depth = 1.
* These requirements can be tested in the SPIR-V validator.

Note that we aren't able to statically test whether the data should be floating-point or integer (Table 13 _Image Data Types_), since the image channel order is still known only at runtime, but testing for scalar data vs. vector data is much better than nothing.

Start with the linked OpenCL environment specification section, especially Section 2.5.2 and Tables 11–13, and review the referenced SYCL discussion for context. The work is done when the scalar/vector requirements are precisely rephrased around the OpTypeImage Depth operand and the corresponding specification changes are agreed, with the proposed validator checks accounted for.

Written by the indexing model from the issue text.