Optional WGSL

This is a meta-issue documenting the usage of WGSL within Nexus. # Summary The idea is that [WGSL](https://gpuweb.github.io/gpuweb/explainer/) will be optional, and avatars will be implemented through the [VRM](https://vrm-consortium.org/) standard. Shaders will be implemented as an extension to the VRM GLTF, clients may optionally use the shader provided via this extension, otherwise, they can fallback to the given VRM shader. ## Philosophy of Design The choice behind this decision is three-fold: 1. WGSL is a complex feature to implement, requiring shader rebuilding, a feature not commonly supported in many game engines 2. Performance, regardless of a theoretical requirement of WGSL, there is still a need for a fallback shader for performance reasons on a client. VRM provides a nice set of shaders we can fallback on regardless. This means a user can still reasonably see an avatar despite having custom shaders. 3. Compared to using another shader language, WGSL by its nature is a language that can be easily sandboxed as its WebGPU parent project lays out the specifications for [GPU sandboxing](https://gpuweb.github.io/gpuweb/explainer/#gpu-process) ## Drawbacks/Blockers Using WGSL is not without a few issues, as has been discussed, WGSL is still relatively new. Therefore, tooling for WGSL is still in its infancy, especially if a user cross-compile their shaders using a tool like [naga](https://github.com/gfx-rs/naga). As @SafariMonkey put it on Discord: > As an example of a scenario where I would expect to see issues, take the scenario of trying to step debug (or edit) the shader in RenderDoc. Either you use WGSL directly and... you are stepping through (or editing) SPIR-V or generated equivalent code, ([source](https://www.reddit.com/r/wgpu/comments/t0lv9j/comment/hycwqxv/), possibly outdated), or you transpile GLSL to WGPU and then that gets compiled to SPIR-V (or generated code) and you almost definitely don't get a source map then. This is one example off the top of my head of the worse experience it may create. This means that a huge part of this problem is outside of the scope of Nexus and is an issue of tooling. Making Nexus a better platform to develop for will mean creating useful, easy-to-use, tooling, especially for WGSL.