Fix 1-frame pause delay

[Pascualex]

Fixes #776. Details available on the issue.

Summary: currently if the user pauses Time<Physics> the pause is delayed by 1 frame because we detect the delta time of the previous frame as if the user had manually advanced the clock. This PR fixed the issue by always resetting the delta time. This shouldn't cause regressions since it doesn't interfere with the 2 standard ways to advance the simulation on the next frame: if the clock is not paused then the delta time will be automatically set at the beginning of run_physics_schedule and if the user manually advances the time then the reset will get overridden.

[Jondolf]

The delay is something we should fix, but the downside with this approach is that reading Time<Physics> in any schedule other than PhysicsSchedule will return a delta time of zero. While accessing it like this is likely rare in practice, it feels wrong that from an outside perspective, it looks like no time has passed for physics. Normally in Bevy, you can read clocks like Time<Fixed> in any schedule, and get the expected result.

Perhaps the fix would instead be to simply reset delta time when physics is paused (like before), and to only advance the simulation when it is not paused. This breaks the old supported approach of manually advancing Time<Physics> and having the PhysicsSchedule be run automatically, but I think this may be fine; manual stepping scenarios can (and arguably should) simply run PhysicsSchedule manually, instead of having it run whenever delta time is non-zero.

[Jondolf]

Although, I suppose manual stepping like that is not necessarily as simple as "just run PhysicsSchedule" since the generic Time resource should be set to Time<Physics> first, and changed back after 🤔 perhaps we could streamline that somehow by automatically configuring the clocks at the start and end of the PhysicsSchedule...

[Pascualex]

Hmmm yeah I don't really the idea of manually advancing a paused clock to continue the simulation. IMO Time<Physics> should only be there to check the latest delta, since it is already tied to a different reference Time. But maybe that's just because I don't have a use case for manual advancement.

If users want to have manual control over Time<Physics>, couldn't they simply do PhysicsPlugins::new(MySchedule) where MySchedule is a schedule that sets a different Time? Or as you said manually call PhysicsSchedule setting a different Time?

My main point here is that it could be cleaner to leave Time<Physics> alone (since it is already tied to a different Time via relative_speed) and instead focus on the higher-level Time. Alternatively, Physics could be an enum with values Relative or Manual, with Manual being a clock that is not pausable and is always reset after advancing the simulation.

But I'm out of my element here, as I said I'm not a user of the manual simulation API.

[janhohenheim]

Related: #661