An entity swapping contexts fails if running in FixedUpdate schedule

[AnthonyTornetta]

Problem

When changing the RapierContextEntityLink component of an entity, I expect it to properly become a part of the new world it was added to. This works correctly if the PhysicsPlugin is being run in the Update schedule, but fails if it is being run in the FixedUpdate schedule.

Reproducible using this code:

https://github.com/AnthonyTornetta/bevy_rapier/blob/master/bevy_rapier3d/examples/change_contexts3.rs

You can test the success case by removing .in_fixed_schedule() on the plugin's initialization. In the failure: as soon as it changes worlds it is not successfully added to the new world, so it just disappears.

I will do some poking around and see if I can fix this.

[AnthonyTornetta]

This seems to be caused by

// These *must* be in the main schedule currently so that they do not miss events.
// See test `test_sync_removal` for an example of this.
if self.schedule != PostUpdate.intern() {
    app.add_systems(
        PostUpdate,
        (systems::sync_removals,).before(TransformSystems::Propagate),
    );
}

Looks like this bug will effect this plugin if run outside of the PostUpdate schedule.

The flow that causes the problem:

1. Context is changed
   a. Old physics components are removed
   b. New physics components are added
2. sync_removals (FixedUpdate) removes those components from the old context's physics backend
3. init_* systems (FixedUpdate) adds the components to the new physics context's physics backend
4. (next frame) sync_removals (PostUpdate) removes the new components that were just added to the context's physics backend, even though we don't want this to happen since it was already handled in the FixedUpdate sync_removals.

I'll see if there's something nice I can do that will prevent this last sync_removals call from running for removed components that were removed in a world change event.

[AnthonyTornetta]

Fixed by #684