Call to textureWeightedQCOM invalid when used in a function

See https://godbolt.org/z/znxjz5e7M for an example. Note that the validator does not complain, but I still think it is invalid. Here is a snippet that I think shows the problem:

```
OpDecorate %wTex WeightTextureQCOM
...
%41 = OpFunctionCall %v4float %foo_tA21_p1_s21_ %weightsTex %weightsSampler %sampleTex
...
%foo_tA21_p1_s21_ = OpFunction %v4float None %16
%wTex = OpFunctionParameter %_ptr_UniformConstant_8
%wSampler = OpFunctionParameter %_ptr_UniformConstant_10
%sTex = OpFunctionParameter %_ptr_UniformConstant_13
...
%29 = OpLoad %8 %wTex
%31 = OpLoad %10 %weightsSampler
%33 = OpSampledImage %32 %29 %31
%34 = OpImageSampleWeightedQCOM %v4float %27 %28 %33
```

Note that `%weightsTex` is not decorated with `WeightTextureQCOM`.

Here is where I think the problem is. In the [SPV_QCOM_image_processing](https://github.khronos.org/SPIRV-Registry/extensions/QCOM/SPV_QCOM_image_processing.html) spec, it describes the `weights` as:

> Weight Image must be an object whose type is OpTypeSampledImage. If the object is an interface object, it must be decorated with WeightTextureQCOM. Otherwise, a texture object which is used to construct the object must be decorated with WeightTextureQCOM. The MS operand of the underlying OpTypeImage must be 0.

The problem is that even though `%wTex` is decorated with WeightTextureQCOM, I don't consider that the object used to construct the sampled image. That would be the parameter on the function call, `%weightsTex`, which is not decorated.

Note the defintion of `object` in the SPIR-V spec:

> Object: An instantiation of a non-void type, either as the Result of an operation, or created through OpVariable.

`%wtex` is not the result of an operation, not is it created through an OpVariable.

This was found because spirv-opt's inliner replaces the operand in the `OpImageSampleWeightedQCOM` instruction, and `%wTex` disappears. Then the validator complains.

Start with the linked Godbolt example and the SPV_QCOM_image_processing specification, then trace how the validator handles WeightTextureQCOM through function parameters. Compare that behavior with the spirv-opt inliner case described in the issue; done means the validator's treatment of the weighted image operand is resolved consistently with the extension rules.

Written by the indexing model from the issue text.