Continuing to add support for more operations. My current plan is to add support for enough operations to run some popular models (open for feedback on which models to focus on) and then go back and work on writing more efficient code the more important operations and dequantization.

In this PR:

• work on the shader generation process to handle different operations which have similar structures, e.g., binary-head.tmpl for ADD and MUL. Note that I'm kinda rolling my own preprocessing through embed-wgsl.py, since WGSL doesn't have any preprocessor support.
• Support for most quantization types for GET_ROWS. A lot of the dequantization code is duplicated in this PR, although I have refactored the i-quant grids so that they are all in one place. I am planning on refactoring the dequantization code when more efficient dequantization, i.e., not a whole block per thread, is implemented, since the structure might change quite a bit.
• As mentioned by @ngxson in ggml : add WebGPU backend #7773, some operations require in-place versions, which is slightly more complex in WebGPU since bindings can't alias. Right now, I do this by having two separate template files, e.g., mul.tmpl.wgsl and mul_in_place.tmpl.wgsl. While the code is basically the same, I want to note that test-backend-ops does not currently have support for testing the in-place versions. Happy to brainstorm what it would take to add support for testing them.
• Metal backends might dynamically change the allowed threadgroup size based on the shader complexity. So for example, on the macOS Github action runner, using the maxComputeInvocationsPerWorkgroup or maxComputeWorkgroupSizeX reported by WebGPU (1024) causes the quantization versions of GET_ROWS tests to fail, and Metal shader validation reported that the max threadgroup size was 704. Since the limits in WebGPU are static, it's not queryable on a per-shader basis. To allow the CI to pass, I have for now hardcoded the workgroup size to 288, and I've also opened an issue with WebGPU (Handling dynamic Metal maxThreadsPerThreadgroup gpuweb/gpuweb#5315) to discuss any possible solutions.
• I also ran into an issue where on the Vulkan LLVMpipe Github action runner, it was failing to execute a loop more than 65535 iterations (whereas the loop needed to execute 78600 iterations). I believe this might just be an issue with the LLVMpipe backend. To fix this, I ended up implementing vectorized f32 GET_ROWS, which is more efficient anyways, but it's something to note going forward.