Allow use of systems for custom time handling

What problem does this solve or what need does it fill?

Bevy is pretty great at handling time (time.delta_seconds() just working in both variable/fixed timestep is some nice UX that other engines don't really have) , but it'd be even better if users could simply take complete control of time for advanced usecases.

Time handling (especially fixed update) is still a bit clunky in a few noticeable ways.

External events like input don't carry any timing information, so there's some aliasing happening.
There is no automatic or built-in tool (such as interpolation) to smoothly render state that updates in FixedMain.
Some users (e.g. networking plugins) would like to control when FixedMain runs but are unable to do so.
Some users would like to disable FixedMain entirely but are unable to do so.

What solution would you like?

Instead of going down the path of adding more parameters and preset[^1] behaviors to address these issues, Bevy could address the root problem of "time isn't configurable enough" by reworking time_system and run_fixed_main_schedule to call other systems that implement the actual behavior, e.g. based on "call this Entity" values stored in a publicly visible resource.

pub fn time_system(world: &mut World) {
    let res = world.resource::<BikeshedMe>();
    let system_id = res.system_id();
    world.run_system(system_id);
}

By turning time_system and run_fixed_main_schedule into dispatchers, a user could control how time is handled by creating their own "one-shot" systems and setting them as the systems that get called instead of the default ones.

[^1]: That being said, I do strongly recommend adding the behavior described in #12465 as a preset for Time<Fixed>.

What alternative(s) have you considered?

The time plugin could keep packing more and more configurable parameters into "official" components/resources.
- I wouldn't like this solution because it puts the onus on Bevy to keep adding and documenting them.
The time plugin could let users provide time_system and run_fixed_main_schedule as configuration.
- I wouldn't like this because it's important to be able to control the behavior at runtime. Other plugins or the editor might want to take control, not just the end user.

I think my proposed solution is more idiomatic and "ECS-y" (systems define behavior) and would let Bevy draw a clear line between "simple" and "advanced" configuration. Any behavior that isn't baked into one of the Time structs would become "advanced use" that users can achieve by overriding the default targets.

Additional context

IMO this is sort of a logical continuation of #8964. That one made whoever's calling (Main or FixedMain) transparent to the systems that are called. This would makes whoever's advancing Time and calling FixedMain transparent.

bevyengine / bevy