Allow users to configure bevy_ggrs main execution point

[adammitchelldev]

This PR gives the user control over precisely when run_ggrs_schedules gets called. Without this change, it's not possible to run bevy_ggrs in any other schedule than PreUpdate when there's no hard requirement for this.

I've based this change on how Avian does it: provide an optional initialization function for the plugin that passes in a schedule label (with a default of PreUpdate as hardcoded currently) and use a public SystemSet for the main execution system to allow the user to configure its execution order and run criteria from outside of the plugin.

I've made this change in a fork so that I can run bevy_ggrs in the RunFixedMainLoop. The exact way I'm doing that feels a bit more like a hack that I don't think is ready to upstream without better simulation management, but the result does feel ergonomic and opens the door to out-of-the-box support for other crates that expect us to be using regular FixedMain e.g. bevy_transform_interpolation.

[johanhelsing]

Looks useful to me. And relatively straightforward implementation.

[gschup]

That's a nice idea! I think it might be confusing to have different config "knobs" in different parts of the code.

We currently have:

• the ggrs session builder
• the GgrsConfig generic thing
• the plugin methods

This would add a fourth way in the Plugin struct itself.

[johanhelsing]

What's your suggestion @gschup ? I like that we follow an established pattern by other major crates like avian, and I'm not even sure if we are allowed to change this post run?

[gschup]

No good suggestion, just an observation. I remember the plugin had more settings in the struct in the beginning.

In the end, it's a good place for static settings to go.

[adammitchelldev]

I don't really think there's another place to put this unfortunately, at least not a nice one, we need to know the schedule by plugin build time because that's when we add the systems.

I've done it in such a way that it shouldn't change existing use of the plugin at all, so GgrsPlugin::<Config>::default() will still work.

[johanhelsing]

Makes sense to me. I'm ok with merging this as is. But maybe something to keep in mind in the future, if we can consolidate some of the other places we configure settings.

[gschup]

Agreed!