Add bevy_gltf settings for animation player and target creation

[greeble-dev]

Objective

Add support for:

• Keeping meshes and animations in separate glTFs.
• Binding meshes to another mesh's animation player.

Background

bevy_animation requires animated entities to have certain components:

• An AnimationTargetId component that identifies which data in an AnimationClip will apply to the entity.
• An AnimatedBy component that points to an entity with a AnimationPlayer component.

bevy_gltf automatically sets up these components if the glTF file contains animations. This works well for glTFs that are self-contained meshes with animations. But it fails for two cases:

1. Separate mesh and animation glTFs.
   • If the mesh glTF doesn't contain any animations then the mesh won't get the components it needs.
2. Binding a mesh to another mesh's animations.
   • Let's say mesh A wants to play the the same animations as mesh B - so the AnimationPlayer on mesh B will drive both meshes.
   • Mesh A wants the glTF loader to give it AnimationTargetId components so it can bind to the animation clips.
   • But it doesn't want AnimatedBy and AnimationPlayer components created automatically - these will be created separately when binding to mesh B's player.
   • See 🧪 Bone attachments #18262 for an example.

Solution

This PR adds the following settings:

/// Decides if the loader will create [`AnimationTargetId`] components. These
/// are used to identify which parts of an [`AnimationClip`] can be applied to
/// a node.
pub enum GltfCreateAnimationTargetIds {
    /// Never create `AnimationTargetId`s.
    Never,
    /// Always create `AnimationTargetId`s. This is typically used when the glTF
    /// does not contain animations itself, but might be bound to animations in
    /// another glTF or some other source.
    Always,
    /// Only create `AnimationTargetId`s for a hierarchy if at least one node in
    /// the hierarchy is affected by an animation within the glTF.
    #[default]
    Automatically,
}

/// Decides if the loader will create [`AnimationPlayer`] and [`AnimatedBy`]
/// components.
///
/// These components are only created if a hierarchy has [`AnimationTargetId`]
/// components (see [`GltfCreateAnimationTargetIds`]). `AnimationPlayer` components
/// are created on the root node of a hierarchy. `AnimatedBy` components are
/// created on all nodes in a hierarchy, alongside the `AnimationTargetId`
/// components.
pub enum GltfCreateAnimationPlayers {
    /// Never create `AnimationPlayer` and `AnimatedBy` components.
    Never,
    /// Only create `AnimationPlayer` and `AnimatedBy` components if
    /// the hierarchy has `AnimationTargetId` components.
    #[default]
    Automatically,
}

The default values work as before. For the two example cases they would be changed:

1. Separate mesh and animation glTFs.
   • Set CreateAnimationTargetIds::Always on the mesh, so it always gets IDs even if it doesn't contain animations.
2. Binding a mesh to another mesh's animation player.
   • Set CreateAnimationTargetIds::Always if necessary, and CreateAnimationPlayers::Never.

The PR also moves the component creation code from load_node to where the scenes are created. This makes the logic a bit simpler, and I think it's nicer if everything is done in one self-contained step rather then being mixed in with other per-node work.

Testing

Tested every combination of settings on a few glTFs with and without animation. Also:

# Check that `bevy_gltf` compiles without `bevy_animation`.
cargo check --no-default-features --features "bevy_gltf"

[ChristopherBiscardi]

This generally seems good and the creation of the target ids as such is a feature that would be useful to have. I think the animation features are a bit complicated and hard to use, but that's not really this PR's responsibility to fix.