Motion vector animated mesh

[JMS55]

Objective

• Add motion vector support to meshes with skins, morph targets, and both skins and morph targets.
• Alternative to Add motion vectors support for animated meshes #9902

Solution

• The new render world resource AnimatedMeshMotionVectors controls whether to enable motion vectors for these types of meshes. TAA enables it by default.
• Lots of complicated logic to bind the previous uniforms for skins and morph targets, and the various combinations thereof
• There are many possible variations:
  1. Motion vectors disabled
  2. Motion vectors enabled, animated mesh support disabled
  3. Motion vectors enabled, animated mesh support enabled, but no uniform buffers last frame (first frame of rendering)
  4. Motion vectors enabled, animated mesh support enabled, uniform buffer from last frame exists, but mesh did not exist/have animated components last frame, and does not have an entry in the previous frame uniform buffer
• Push constants are used to handle case 4, where the push constant (0/1) masks out the motion vector.
  • Probably should think more about this, as it'll break TAA on WebGPU. A new bit in MeshFlags might be better, but the flags are built in extract_meshes_for_cpu/gpu_building, and we won't know whether to sit the bit or not until after extract_skins and extract_morphs...
• Also removed the old push constant usage left around from the old instance_index.wgsl workaround, which got removed at some point

TODO

• Modify SetBindGroup to set the dynamic offsets for previous frame morph and/or skin buffers when they are bound, and set the appropriate push constant.
• Modify prepass.wgsl to calculate previous_world_position for skinned and/or morph target meshes.
• Update prepass example to show animated meshes
• Docs

---

Changelog

This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.

• What changed as a result of this PR?
• If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
• Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
  • If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!

Migration Guide

This section is optional. If there are no breaking changes, you can delete this section.

• If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
• Simply adding new functionality is not a breaking change.
• Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.

[JMS55]

This is too much of a pain :/