Specifying only `f32`/`f64` features without `parry-f32`/`parry-f64` features causes a panic without an obvious cause

[datael]

trafficstars

Noticed this when pinning down https://github.com/Jondolf/avian/issues/505.

Disabling Avian's default features in Cargo.toml and a combination below causes a panic:

• Specifying f32 without also specifying parry-f32
• Specifying f64 without also specifying parry-f64

https://github.com/Jondolf/avian?tab=readme-ov-file#more-examples briefly mentions that you need to specify parry-f64 alongside f64 to run examples in f64 mode.

I can see a case where this is considered "enough", and if so please feel free to close this ticket.

Panic logs

With avian3d = { version="0.1", default-features = false, features = ["3d", "f32", "parry-f32", "serialize"] }

thread 'main' panicked at /Users/datael/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.2/src/schedule/schedule.rs:383:33:
Error when initializing schedule PhysicsSchedule: Systems with conflicting access have indeterminate run order.
10 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these:
 -- propagate_collider_transforms (in set First) and run_substep_schedule (in sets Solver, Substep)
    conflict on: bevy_ecs::world::World
 -- propagate_collider_transforms (in set First) and wake_on_collision_ended (in set ReportContacts)
    conflict on: ["avian3d::collision::collider::ColliderTransform"]
 -- update_child_collider_position (in set First) and wake_on_changed
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and <SolverPlugin as Plugin>::{{closure}} (in sets PreSubstep, Solver)
    conflict on: ["avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and apply_impulses (in set Solver)
    conflict on: ["avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and run_substep_schedule (in sets Solver, Substep)
    conflict on: bevy_ecs::world::World
 -- update_child_collider_position (in set First) and solve_restitution (in sets Restitution, Solver)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and apply_translation (in sets ApplyTranslation, Solver)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and wake_on_collision_ended (in set ReportContacts)
    conflict on: ["avian3d::position::Position"]
 -- update_child_collider_position (in set First) and update_ray_caster_positions (in set SpatialQuery)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]

With avian3d = { version="0.1", default-features = false, features = ["3d", "f64", "parry-f64", "serialize"] }

thread 'main' panicked at /Users/datael/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.2/src/schedule/schedule.rs:383:33:
Error when initializing schedule PhysicsSchedule: Systems with conflicting access have indeterminate run order.
10 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these:
 -- propagate_collider_transforms (in set First) and run_substep_schedule (in sets Solver, Substep)
    conflict on: bevy_ecs::world::World
 -- propagate_collider_transforms (in set First) and wake_on_collision_ended (in set ReportContacts)
    conflict on: ["avian3d::collision::collider::ColliderTransform"]
 -- update_child_collider_position (in set First) and wake_on_changed
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and apply_impulses (in set Solver)
    conflict on: ["avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and <SolverPlugin as Plugin>::{{closure}} (in sets PreSubstep, Solver)
    conflict on: ["avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and run_substep_schedule (in sets Solver, Substep)
    conflict on: bevy_ecs::world::World
 -- update_child_collider_position (in set First) and solve_restitution (in sets Restitution, Solver)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and apply_translation (in sets ApplyTranslation, Solver)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]
 -- update_child_collider_position (in set First) and wake_on_collision_ended (in set ReportContacts)
    conflict on: ["avian3d::position::Position"]
 -- update_child_collider_position (in set First) and update_ray_caster_positions (in set SpatialQuery)
    conflict on: ["avian3d::position::Position", "avian3d::position::Rotation"]

Extra information

This is just a guess, but the complete lack of either ColliderBackendPlugin or NarrowPhasePlugin may be what causes these panics, so I'm not sure that there's any obvious solution here.

Since custom colliders are supported and require manually adding those two plugins, I don't believe that Avian's usual approach of putting feature-gated compile errors would be appropriate in this case.