Allow SPIR-V shaders to process when shader defs are present

[Shfty]

Objective

• Prevent SPIR-V shaders from being rejected when shader defines are present.

Solution

• Have ShaderProcessor behave as a passthrough with respect to SPIR-V shaders.

---

Fixes #7771

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[Shfty]

Any chance of that review, @superdump?

If this relatively small change ends up merged, Bevy Rust-GPU will be a step closer to providing a WGSL-comparable workflow for rust-gpu shader crates in mainline bevy.

[mockersf]

Would it makes sense to log a message saying something like "loaded a SpirV shader, it will ignore shader defs"?

[Shfty]

I'd have thought that would be implicit, or something that would belong documentation-side if anything; the processor is either interested in SPIR-V or not, so my initial feeling is that it would end up filling the log with obvious statements in a project that makes extensive use of the format.

However, @superdump suggested an alternate approach on Discord that seems less intrusive; keeping the hard error, but giving Material implementors the opportunity to clear out all built-in shader defs at specialization time.

Currently NO_*_SUPPORT and SIXTEEN_BYTE_ALIGNMENTget injected after the fact and create the hard error situation this PR aims to remedy, so moving them earlier in the pipeline would avoid breaking the processor's existing assumptions while simultaneously allowing Material the control it needs for the use-case.

I was planning to open another pull to that effect anyway, so will take a swing at it and see where things go from there.

[Shfty]

New PR: #7903

[brynnbrancamp]

This is super important for a (edit: Spirv utilizing) subset of bevy users and we need a solution.

[mockersf]

needs to be rebased before it can be merged