Fix get_global_transform_interpolated() with multiple ticks per frame

[lawnjelly]

The previous and current transforms in the interpolation data were not being correctly updated in cases where two or more physics ticks occurred on a frame. This PR introduces a simple mechanism to ensure updates on interpolated spatials.

On suggestion from reduz this now uses a SelfList to store the list of Spatials to update, and this list is stored in the SceneTree. Members of this update list have a timeout value in order to reduce processing - if get_global_transform_interpolated() has not been called in a certain number of physics ticks, it is removed from the update list until the next time get_global_transform_interpolated() is called.

Note that the update list ONLY copies the current transform to the previous transform and updates the global transform. It does not perform any interpolation, that is performed on request within the get_global_transform_interpolated() function.

Explanation

Previously, if there were 2 or more physics ticks in a frame (for instance setting physics tick rate to 90tps, at a frame rate of 60fps), then the previous transform would only be set once, and would end up being a stale previous transform, which would result in the the interpolated value being further back in time than it should be, giving a visual effect of jitter.

Notes

• This bug only occurred when using client interpolation using the get_global_transform_interpolated() function (e.g. for a Camera).
• It only occurs when the tick rate is high enough that 2 or more physics ticks occur per frame (which is why I didn't notice it earlier).
• The exact same bug also came up in the smoothing addon (!) 😁

[reduz]

I think since this is a SceneTree related variable, it may be better to just put it SceneTree rather than here or in engine. Nodes have access to it via get_tree()

[lawnjelly]

Ok I'll take a look at this, could be better in a second PR maybe? (as is only side related to the interpolation, just used as a fallback for if get_global_transform_interpolated() was called from e.g. _process())

And it is a compatibility breaking change, so would benefit from some separate scrutiny.
EDIT - Yes it looks a little more involved than it may appear, because the Input depends on checking this, and due to timing of Input it may not be a good idea just to set it on and off at the beginning and end of SceneTree::iteration.

This line was a simple fix for an existing bug incidentally - the situation when exiting the app, the in_physics flag was never set to false (I picked this up when debug outputting error messages if get_global_transform_interpolated() was called from inside the physics.

[reduz]

I think this looks good, it remains to be seen how well it works when users test it, but I am positive.

Changes for a follow up PR.

[akien-mga]

Thanks!