Physics backend decoupling

[LeXXik]

This is a follow up on #9043. Which was a quick merge, sorry, didn't have time to review, but happy to see it addressed!

One comment I had to mention is probably what Max implied. We would want a system that would allow the backend to drive what components it would use for the frontend. Trying to shape another physics engine into Ammo rigidbody and collision components is not feasible, unless we strip down all its functionality to the bare minimum and even then it would be mostly workarounds over an artificial constraint. Ammo components are tailored for Ammo, and we'd want to have other backends to be handled by their respective frontend components.

Another point was about introducing (bringing back?) a fixed update method to scripts. Ammo handles interpolation for us, but other engines don't. We can say a backend can handle fixed update and interpolation internally, but I still think we want the engine to drive it. There is enough use cases (procedural stuff, light, etc) that we don't want/need to run every frame. An engine side fixed update could be of a benefit here for all systems. Could be in another PR.

Going to review the PR later tonight and see if I have anything to add to what @AlexAPPi and @Maksims already covered.

[AlexAPPi]

This is a follow up on #9043. Which was a quick merge, sorry, didn't have time to review, but happy to see it addressed!

One comment I had to mention is probably what Max implied. We would want a system that would allow the backend to drive what components it would use for the frontend. Trying to shape another physics engine into Ammo rigidbody and collision components is not feasible, unless we strip down all its functionality to the bare minimum and even then it would be mostly workarounds over an artificial constraint. Ammo components are tailored for Ammo, and we'd want to have other backends to be handled by their respective frontend components.

Another point was about introducing (bringing back?) a fixed update method to scripts. Ammo handles interpolation for us, but other engines don't. We can say a backend can handle fixed update and interpolation internally, but I still think we want the engine to drive it. There is enough use cases (procedural stuff, light, etc) that we don't want/need to run every frame. An engine side fixed update could be of a benefit here for all systems. Could be in another PR.

Going to review the PR later tonight and see if I have anything to add to what @AlexAPPi and @Maksims already covered.

We have repeatedly returned to the idea of a fixed timestep, and the new approach simplifies its implementation.

For custom interpolation via getTransform, implementing a fixed timestep becomes easier: the fixed step naturally fits inside the step method.

At the same time, contact handling may require more complex logic for Jolt, since its approach is somewhat inverted.

I'll try to implement a Jolt wrapper in the near future.