allow optional image operands for image write instructions

[bashbaug]

fixes #854

The OpenCL SPIR-V environment spec currently says that image write instructions must not include an optional Image Operand. While this was borderline true in the past - there was no usage with core OpenCL functionality, but it was used by cl_khr_mipmap_image_writes to pass the Lod - it is definitely no longer true now for things like Nontemporal. So, instead of banning an Image Operand for image write instructions, we can instead apply the same restrictions to image write instructions that we apply to image read instructions.

Additional notes:

• If we chose to, we could support the ConstOffset Image Operand also, so long as the only supported ConstOffset is all zeroes. This isn't very useful, though, and we would need to add it to the SPIR-V LLVM Translator, and we would need additional testing.
• Here is a test that passes the optional Image Operand Nontemporal to OpImageWrite: https://github.com/KhronosGroup/OpenCL-CTS/blob/e936977934ac450d8bb7c66635c02105a29f7ea8/test_conformance/spirv_new/spirv_asm/spv1.6/image_operand_nontemporal.spvasm64#L28
• I don't see any tests that pass the optional Image Operand SignExtend or ZeroExtend to OpImageWrite, either in the CTS or in the SPIR-V LLVM Translator tests. Is this something we should add, or am I just not finding it?

[bashbaug]

Answering my own question:

• I don't see any tests that pass the optional Image Operand SignExtend or ZeroExtend to OpImageWrite, either in the CTS or in the SPIR-V LLVM Translator tests. Is this something we should add, or am I just not finding it?

I don't think this is necessary. For the integer image formats, the data we pass to OpImageWrite is always a 32-bit integer, at least currently: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_data_format_for_reading_and_writing_images

Since we don't support image formats with channel data bigger than 32-bits, there is no need to sign extend or zero extend.

Tagging @svenh for confirmation, since SignExtend and ZeroExtend were explicitly mentioned as operands to OpImageWrite in #854.

[bashbaug]

Merging as discussed in the September 2nd teleconference.