Refactor and speed up transform propagation and hierarchies further

[Jondolf]

Objective

#377 refactored collider hierarchy logic and extracted it into a ColliderHierarchyPlugin<C: ScalableCollider>, along with significantly speeding up ColliderTransform propagation using a ColliderAncestor marker component to ignore trees that don't have colliders.

However, a similar marker component approach can also be used to speed up the many copies of transform propagation that the engine has. By limiting the propagation runs to physics entities, we could drastically reduce the overhead for scenes with lots of non-physics entities, further addressing #356.

Solution

• Extract the ancestor marker logic from ColliderHierarchyPlugin into an AncestorMarkerPlugin<C: Component> that adds an AncestorMarker<C> component for all ancestors of entities with the given component C. The logic was also refactored to be more robust and fix some edge cases and fully support hierarchy changes, along with adding more tests.
• Use this plugin in SyncPlugin to mark rigid body ancestors.
• Define custom transform propagation systems that only traverse trees that have physics entities (rigid bodies or colliders). See the comments in sync.rs above the propagation systems to see how this works.
• To support custom collision backends without having to add generics to all the propagation systems, and to avoid needing to unnecessarily duplicate systems, the ColliderBackendPlugin now adds a general, automatically managed ColliderMarker component for all colliders, which allows filtering collider entities without knowing the collider type. This lets us get rid of the generics on ColliderHierarchyPlugin!
• I also changed some scheduling and system sets in the PrepareSet to account for some changes and to be more logical.

Results

Test scene: 12 substeps, 1 root entity, 100,000 child entities. All entities have just a SpatialBundle, and one child entity also has a Collider.

• Before #377: ~22 FPS
• After #377: ~200 FPS
• After this PR: ~490 FPS

Of course, this scene is not very representative of an actual game scene, but it does show just how much of an impact the transform propagation was having. A lot of games (probably most of them) do have many more non-physics entities than physics entities, and the overhead added by the marker components and new checks should be very minimal in comparison.

---

Migration Guide

Some PrepareSet system sets have changed order.

Before:

1. PreInit
2. PropagateTransforms
3. InitRigidBodies
4. InitMassProperties
5. InitColliders
6. InitTransforms
7. Finalize

After:

1. PreInit
2. InitRigidBodies
3. InitColliders
4. PropagateTransforms
5. InitMassProperties
6. InitTransforms
7. Finalize

Additionally, the ColliderHierarchyPlugin added in #377 no longer needs generics. The plugin is new anyway however, so this isn't really a breaking change.