Exposed step(), save_state(), and restore_state() to GDScript

[TypicalFooBar]

Description

The step(), save_state(), and restore_state() functionality of Jolt has been exposed to GDScript. Alongside those, the physic engine's set_active() function has been exposed to allow pausing/unpausing the simulation.

Usecase

I wanted my game server to be able to step through the physics simulation as quickly as possible and have it save state every physics frame along the way in order to then send it to the game clients to have them replay, pause, fast-forward, etc. the "replay" of the physics simulation.

Notes

• I do not have much experience with Jolt or godot-jolt, so I am unsure if this is the most proper way to expose this functionality. I'm happy to take feedback and tweak this pull request as needed. If you think that there is a better way to go about this and you want to be the one to make the change in this PR, please do so!
• I have included an example Godot scene to test this functionality out. Please review the step_save_restore.gd file for an example of how this functionality can be used.

Appreciate ya!

[TypicalFooBar]

Here is a discussion for reference.

[mihe]

As touched upon in #623 already, what your PR does is only save the state that Jolt cares about internally, and none of the state that is kept within the extension itself. While that may work/look fine in something like your relatively simple example scene, something like freeing a single RigidBody3D will make this whole thing explode when you rewind before that point, not to mention the potentially subtle bugs that will arise from rewinding before some extension-specific state was modified.

Jolt does accommodate for this to some extent, by letting you save arbitrary state into its StateRecorder, but this adds not only complexity but also a not insignificant maintenance burden that I'm not very keen to take on.

But, more importantly, as also touched upon in #623, I believe that a feature like this should propagate from Godot itself rather than be "sideloaded" through this extension, so frankly I would be ready to reject this change on nothing but principle even without the above mentioned problems.

Going the route of packing this extension full of Jolt-specific features can also potentially get in the way of migrating this whole thing into Godot core at some point (which is certainly not in any plans, but seems to be a popular sentiment) since JoltPhysicsServer3D would go away and some sort of new common ground would have to be established with Godot Physics in the regular PhysicsServer3D interface.

[TypicalFooBar]

Makes sense! Appreciate your feedback. With no other alternative (for now), I'll use this setup for state recording on the server and replay on the clients until Godot has tweaked how we can interact with the physics system for this use case.