feat: implement F16 support in shaders

[FL33TW00D]

Connections

• Hard dependency on WGSL: Add a skeleton for enable-extensions/enable …; that reports nice errors #6424.
• Resolves WGSL: Support the enable directive #5476.
• Resolves [meta] f16 support #4384.

Checklist for merge-ability

• Test multiple redundant directives (I think there may be a cleaner way to do this: https://github.com/gfx-rs/wgpu/pull/5701/files#diff-9ef835ffc5f7d7313243db5bfa371d3115b82c0705d4f1df75c98dfe07d927a1R2175)
• MSL out
• HLSL out
• SPV out
• Arbitrary for F16 on half-rs: feature: Arbitrary starkat99/half-rs#111. Currently we are using a git dep on my fork which is causing CI to fail.
• hexf_parse f16 support: https://github.com/lifthrasiir/hexf. This one won't be fun. Did some work on it here: lifthrasiir/hexf@master...FL33TW00D:hexf:feature/f16 .
• We should make sure that we are properly validating As casts of matrices, because that code currently assumes that all matrices have the same kind (Naga's typechecker ignores scalar kind when casting matrices #6441).

Additional context

F16 is available in >=SM6.2: https://github.com/microsoft/DirectXShaderCompiler/wiki/16-Bit-Scalar-Types

[FL33TW00D]

I've marked this as ready for review, as the wgpu specific logic is implemented and would be great to start iterating on it.

2 main blockers are:

1. Merging of the PR on half-rs.
2. hexf-parse improved implementation.

[FL33TW00D]

Dogfooding works! Fixed a few bugs in 30e12b5. Still waiting on upstream.

[teoxoy]

One thing I'm concerned is that the polyfills we have in some of the backends might not support f16. It would be worth adding more tests covering the built-in functions and operations that support f16. Execution tests would be great as well, they live in tests/tests/shader.

[teoxoy]

It is possible to use FP16 in user-defined pipeline input/output variables. However some Vulkan devices, which support other usages in this extension like FP16 built-in function and storage buffer, don’t support this usage. For capabilities reasons, we may suggest not enabling using FP16 as pipeline input or output with this extension. However, this usage can also be emulated on Vulkan devices with no native support for this usage (storageInputOutput16).

from gpuweb/gpuweb#2512

I think we have to do the casting ourselves. Dawn also seems to do this. We can do it in a different PR though.

What I find interesting is that the proposal talked about SM6.2 & Native16BitShaderOpsSupported enabling support for f16 IO, I guess the Nvidia compiler that ingests DXIL will do the casting. It probably does the casting regardless of frontend and that's why people report this working on Vulkan as well despite storageInputOutput16 not being supported. While it's unlikely this will change we shouldn't rely on this behavior.

[jimblandy]

We should make sure that we are properly validating As casts of matrices, because that code currently assumes that all matrices have the same kind (#6441).

[raphamorim]

Super awesome work folks, really appreciate it!! 👏 <3
@FL33TW00D please lemme know if I can help in anything 🙏