Enable VK_KHR_vulkan_memory_model

[kvark]

Is your feature request related to a problem? Please describe.
A pass-through of SPIR-V shaders with Vulkan memory model triggers validation.

Describe the solution you'd like
WebGPU is adopting the memory model similar to Vulkan.
Therefore, Vulkan backend should try to enable this extension (unless its on Vulkan 1.2), unconditionally.

Describe alternatives you've considered
Exposing this as an optional feature.

Additional context
Add any other context or screenshots about the feature request here.

[teoxoy]

Spec PR gpuweb/gpuweb#2055 (related: gpuweb/gpuweb#1621)

[jimblandy]

If I understand correctly, the extension describes behavior that drivers already provide, and the extension just describes and formalizes it. So:

• If the extension is available, we should request it.
• If the extension is not available, we should assume the device behaves that way anyway.

[inner-daemons]

Looks like this will interact with #4444, which will have to handle vulkan memory model as a similar but separate problem, probably with an uglier solution.

In particular, see the memory operands field on many SPIRV methods, like OpLoad. In particular, NonPrivatePointerKHR would be needed on EVERY access to specify that it might interact with other threads, MakePointerVisibleKHR would be needed on reads, and MakePointerAvailableKHR would be needed on stores.

I'm not too familiar with naga's spirv-writer but this seems like it would be annoying.

[inner-daemons]

Also, #8251 introduced this somewhat already. However it is only added if cooperative matrices are enabled