Allow ordering variable timesteps around fixed timesteps

[janhohenheim]

Objective

• Fixes Bevy has no clear schedule for updating a camera's Transform when using a fixed time step #14873, see that issue for a whole lot of context

Solution

• Add a blessed system set for this stuff. See this Discord discussion.

Note that the gizmo systems, LWIM and now a new plugin I'm working on are all already ordering against run_fixed_main_schedule, so having a dedicated system set should be more robust and hopefully also more discoverable.

---

Showcase

I can add a little video of a smooth camera later if this gets merged :)
Apparently a release note is not needed, so I'll leave it out. See the changes in the fixed timestep example for usage showcase and the video in #14873 for a more or less accurate video of the effect (it does not use the same solution though, so it is not quite the same)

Migration Guide

run_fixed_main_schedule is no longer public. If you used to order against it, use the new dedicated RunFixedMainLoopSystem system set instead. You can replace your usage of run_fixed_main_schedule one for one by RunFixedMainLoopSystem::FixedMainLoop, but it is now more idiomatic to place your systems in either RunFixedMainLoopSystem::BeforeFixedMainLoop or RunFixedMainLoopSystem::AfterFixedMainLoop

Old:

app.add_systems(
    RunFixedMainLoop,
    some_system.before(run_fixed_main_schedule)
);

New:

app.add_systems(
    RunFixedMainLoop,
    some_system.in_set(RunFixedMainLoopSystem::BeforeFixedMainLoop)
);

[janhohenheim]

Addressed all replies. I made run_fixed_main_schedule private as it is no longer needed, given that we have a proper system set now. I also showcase the new set with its intended usage in the fixed timestep example. Feel free to tell me to revert it if it is too big now; the changes are not strictly necessary, I just thought it would be a neat place to make users aware of this.
I also added the release note label given that this will help people deal better with a fairly common issue when working with fixed time steps. I can add nice little video showing the effect side-by-side in a first-person example, if you want :)

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[chescock]

Having a dedicated system set seems much cleaner than ordering against the system name!

What's the advantage of having three sets versus just one, though? Could you remove the BeforeFixedMainLoop and AfterFixedMainLoop variants and just use some_system.before(RunFixedMainLoopSystem::FixedMainLoop) and some_system.after(RunFixedMainLoopSystem::FixedMainLoop)? You could even shorten it from an enum to a unit struct.

(I see @NiseVoid's comment about running "after all the other before things but before FixedMain", but I don't think there is any ordering between in_set(BeforeFixedMainLoop) and before(FixedMainLoop); they're just both before in_set(FixedMainLoop). And even if there is, you'd have ambiguities if two systems both wanted to run last, so the extra label wouldn't fully solve the problem.)

[chescock]

It might be worth noting in the doc comments that the RunFixedMainLoop schedule uses ExecutorKind::SingleThreaded, so nothing scheduled using these sets will have system-level parallelism. That's unusual for built-in schedules that users add systems to.

[janhohenheim]

@chescock the ordering comes from foo.after(FixedMainLoop).before(AfterFixedMainLoop).
Bottom line is that using multiple variants is cleaner as you get a definitive place to use .in_set with. Plus, this won't break in the unlikely case where we split FixedMainLoop into multiple system sets.

As for the single-threaded stuff: good point, definitely worth noting or even changing entirely

[alice-i-cecile]

IMO we shouldn't change it, but it should be noted in the docs for the schedule.