Fix OpImageRead result type when compiling HLSL (#2706)

Fix OpImageRead result type when compiling HLSL

- Per the Vulkan spec, OpImageRead must return a 4-component vector always. When compiling HLSL, loads from a RWTexture of a template type with < 4 components would incorrectly generate an OpImageRead with a < 4 component result, resulting in validation errors.
- This was previously fixed for OpImageFetch in commit 4425f24; this commit does the same thing for OpImageRead.
- Added associated tests and expanded existing image fetch tests to check all the different types of textures, in both float and int incarnations, for completeness.
- Update other HLSL tests involving OpImageRead

SPIRV/GlslangToSpv.cpp

@@ -5317,7 +5317,10 @@ spv::Id TGlslangToSpvTraverser::createImageTextureFunctionCall(glslang::TIntermO
 
     int components = node->getType().getVectorSize();
 
-    if (node->getOp() == glslang::EOpTextureFetch) {
+    if (node->getOp() == glslang::EOpImageLoad ||
+        node->getOp() == glslang::EOpImageLoadLod ||
+        node->getOp() == glslang::EOpTextureFetch ||
+        node->getOp() == glslang::EOpTextureFetchOffset) {
         // These must produce 4 components, per SPIR-V spec.  We'll add a conversion constructor if needed.
         // This will only happen through the HLSL path for operator[], so we do not have to handle e.g.
         // the EOpTexture/Proj/Lod/etc family.  It would be harmless to do so, but would need more logic