Fix interpolation and systems schedule

[Vixenka]

Interpolation not works properly due the problem described in #464.

We removed TimestepMode from crate, because we do not see reason for why this should even exists. Idea of FixedUpdate loop which Bevy engine implements look fine, and another game engines also use this for physics steps. Description about current master implementation:

• TimestepMode::Fixed - looks nice, but do not interpolate results, who wants to use that? This can be easy misleading for new users of crate.
• TimestepMode::Variable - it make physics heavily addicted by Update's delta time and is really far of deterministic, also change speed of physics depending on render time which makes difficult to catch up render by physics what occurs slow simulation on e.g. weaker computers.
• TimestepMode::Interpolation - before does not work correctly, user system execution was skipped and lerp was poorly implemented.

Now, after our changes, every user defined system which impact physics like movement etc. should execute in engine's schedule FixedUpdate and before crate's system set PhysicsSet::SyncBackend. Also for things like slow motion effects change engine's fixed delta time by Bevy API.

Resolves #464, resolves #379, closes #463 And probably #465, #475

[andriyDev]

As discussed in #475, the velocity is not correctly reported for KinematicCharacterControllers (it always seems to print 0.0).

It also looks like this PR makes the KinematicCharacterController translation field use meters per second, rather than units (or pixels) per second. This is a change from the existing behavior.

Edit: I'll try to review this and see if I spot anything.

[phisn]

The current implementation does not allow for a lot of flexibility of schedule design anymore. My game uses a custom schedule to have more control over the physics loop which is not possible here anymore. Maybe we could define a self.physics_schedule and self.write_back_schedule to differentiate between both use cases. This can not be easily fixed by putting my systems before or after the rapier system set since it does not allow for not executing or executing irregularly.

[phisn]

I also just noticed, that when the transform is changed, that the whole interpolation is canceled. In my game im currently setting the rotation in each frame but do still like the translation to be interpolated. Maybe its possible to do the interpolation component wise?

[Vixenka]

@phisn about custom schedules we need to have the expected behavior from #464 to have working interpolation. Bevy's FixedUpdate schedule was created for this purpose, and suits for this ideal. I do not know, why you want to replace this from API, because way how it works after my changes are so common in another game engines, and games just exists with that solution. But maybe you want to have possibility for execute next physics step by hand? Then user-defined systems should also be executed what I do not remember if it possible in Bevy to make (I guess yes), and this is a things what we can make (if we can).

About transform changes, and preverting interpolation. This exists originally in code, and this is a feature what have sense, because make teleporting instant instead of flying all over the map. Real world physics do not have things like teleport, everything works with impulses and forces, not by teleporting, and teleporting is not a things what can be interpolated, because physics engine do not know what changed in what way. You can create impulse or force, what will be rotate your object with having interpolation, or also add rotation similar to position to character controller what Rapier do not implement yet.