Optimise shaders

## What problem does this solve or what need does it fill?

Now with more complex scenes, bevy_pbr at least is GPU bound and usually by the fragment shader stage. As far as I am aware, there has not yet been an effort to understand how to optimise shaders, and to then do so.

## What solution would you like?

- Gather resources on shader optimisation and share with the community
- Profile and investigate the bevy core shaders
- Optimise them, testing and documenting the changes as we go

## What alternative(s) have you considered?

- Not optimising them and lamenting the lost frames

## Additional context

I poked a bit at the PBR fragment shader for some of the 'new Sponza' scene meshes, the heavier ones such as the green mesh geometry screenshots below. In Xcode's GPU frame profiler, it shows that the uniform control flow from the StandardMaterial flags does incur a performance cost. Removing those, such as `if ((material.flags & STANDARD_MATERIAL_FLAGS_BASE_COLOR_TEXTURE_BIT) != 0u) {` and making them unconditional caused a reduction in the fragment stage execution time for that mesh, according to Xcode, of 2.34ms -> 1.88ms = 0.46ms, which is a ~20% reduction. Very significant. This testing that I did was with BC7 textures on an M1 Max.

170k triangles in one draw, covering a relatively small region of the screen.

Zoomed in on a small section of that mesh to observe the tesselation.

Also, @jakobhellermann was looking into the same scene using AMD Radeon GPU Profiler and found that the fragment shader occupancy was 3/10 on their GPU, and that we're using 69 VGPR (72 allocated) and 54 SGPR (64 allocated). This testing by Jakob is using uncompressed textures, but scaled down from 4096x4096 to 1024x1024 to save RAM.

My understanding is that this low occupancy is pretty bad indeed. I wonder what @aclysma sees in rafx and @cwfitzgerald in rend3 on the same scene.