Problem

Linear sampling (or "filtering") can only be done with textures that have GPUTextureComponentType.float. The shaders know about the component type of textures, but the shaders don't know if a sampler is filtering or not. So shader translation can't validate this, and outside of the shader, on the API side, we no longer know which textures are used with which samplers.

Solutions

1. allow the filtering to be done on non-float textures, specify this as "undefined result" or something. It may be unfeasible if there is an UB in the driver/HW, and it's obviously not very portable (but the choice is provided for completeness!).
2. have the shader translation to generate a map of texture-sampler pairs, which will then be used by the validation at the draw time (!) where all the bindings are known, and we can check the samplers.
3. introduce a new GPUBindingType::"filtering-sampler" (in addition to regular "sampler" and "comparison-sampler") with the corresponding distinction in WGSL. This would mean:
   - createShaderModule can fail if we see that a filtering sampler is used with an incompatible texture
   - createBindGroupLayout can fail if the given sampler doesn't match the binding
   - no heavy validation at draw time

Details

If we go (3) one concern could be raised about how the translation from other languages, like SPIR-V, would know what type of the sampler to use. To some extent, it fits under the current umbrella of sampler diversity (we have a "comparison" sampler type that SPIR-V doesn't). As proposed in #889, we could generate multiple conflicting bindings for the SPIR-V sampler, and it will all work fine as long as only one of the multiple (regular/comparison/filtering) is used statically for any given entry point.