Unify FixedTime and Time (ver. B) (proof-of-concept)

[maniwani]

This is an alternative to #8930 (pretty similar though).

(credit to @devil-ira for suggesting this idea to me months ago)

As a quick background, both Update and FixedUpdate follow "virtual" time (time that can be sped up, slowed down, and paused) but each needs its own clock to measure it because they advance at different rates.

Objective

I wrote this PR to make the Time API usable in FixedUpdate, with the goal of making plugin systems more portable. If Time is setup so the clock is correct in both Update and FixedUpdate, then users can write and import systems that access Res<Time> and they'll always work no matter which scheduled they're added to.

This would take us off a path that leads to some really annoying compatibility issues that plague third-party code in other engines (e.g. store assets for Unity) because their logic can't be freely moved between their Update and FixedUpdate equivalents.

Some other issues:

• If running FixedUpdate takes longer than the fixed timestep, the app can enter a "death spiral" and ultimately freeze as each frame sees an ever-increasing queue of FixedUpdate steps and never catches up.
• If there is a particularly long gap between app updates (e.g. the program was suspended), time will jump¹ forward a lot all at once, which translates into a huge FixedUpdate simulation debt. The app will seem to freeze until it catches up.

Solution

• Split common functionality into a Clock data structure to reduce code duplication.
• Make Time report "fixed time" while running FixedUpdate.
• Add a setting to directly limit the number of FixedUpdate steps per frame. This will spread "paying off a large simulation debt" over multiple frames.
• Add a setting to set a maximum delta time per frame. This will limit the impact of program suspends (by indirectly limiting how many FixedUpdate steps can build up between two updates).

I moved the "real time" (same speed as Instant) clock into a separate RealTime resource. Maybe having all three clocks crammed inside Time would have been better, but (1) I didn't like the look of having clock-specific methods (e.g. time.delta(), time.raw_delta(), time.fixed_delta()) and (2) "real time" is pretty meaningless in FixedUpdate. More breaking changes though.

I've also kept a FixedTimestep struct because keeping the step size and accumulator separate from the clock is much cleaner IMO and leaves room for, say, a networking plugin to sub in its own handling (without requiring more API from us).

Migration Guide

• Use FixedTimestep and Time instead of hard-coded constants.
• Replace FixedTime::period with Time::delta.
• Replace other FixedTime methods with FixedTimestep equivalents.
• on_fixed_timer has been removed. Replace it with on_timer as Time now works correctly in both schedules.

Footnotes

1. On some platforms. ↩

[maniwani]

Closing in favor of #8964.