Load FXC dynamically to remove the dependency on d3dcompiler_47.dll

[RedMindZ]

Connections
Implements #7531.

Description
Currently, wgpu statically links d3dcompiler_47.dll, even though it is only required for FXC, which is probably very rarely used. This increases the size of the executable and reduces compatibility, even if only slightly.
This PR loads d3dcompiler_47.dll dynamically, removing the dependence on it.

To achieve this, we change dxc_container to a generic compiler_container which is an enum that holds the relevant data for each compiler variant: Fxc, DynamicDxc, and StaticDxc. Only the DX12 shader compiler variant specified by the user is loaded.

Previously, the shader_compilation module exposed multiple functions to create a container and compile shaders.
Now, everything has been unified under the new CompilerContainer enum which exposes new_* functions to create the appropriate compiler container, and a compile function which will call the appropriate implementation for each of the different compilers.

There is one thing I am unsure about and would like to get your feedback on: In this PR, every call to D3DCompile reloads the function from the dll using libloading due to the lifetime imposed by libloading. I chose this route because it is safe, but it is clearly not very performant. A better option would be to obtain a pointer to the function, and reuse that pointer every time. The thing that stopped me from going down that route is that I don't know if the library is pinned in memory once it is loaded. If it is, we can simply keep a pointer to the function in the same struct that holds the library; If the library is not pinned in memory, it would be incorrect to store the pointer.

Testing
Tested using cargo test and running my wgpu/bevy based application, both work as expected.
Additionally, using windows' dumpbin /dependents <executable> no longer shows d3dcompiler_47.dll as a dependent.

Squash or Rebase?
Squash

Checklist

• Run cargo fmt.
• Run cargo test.
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[cwfitzgerald]

If it is, we can simply keep a pointer to the function in the same struct that holds the library; If the library is not pinned in memory, it would be incorrect to store the pointer.

Yeah the lifetime is there to make sure the library isn't unloaded while the function pointer is hanging around. It's perfectly sound to pull a pointer and continue using it for the life of the module. if something needs to move the instructions around, it would expose a trampoline function with a stable address.

[cwfitzgerald]

One small comment, will do a more proper review later

[cwfitzgerald]

Nice stuff!