Fix SoftBody - update rendering server once per frame.

[lawnjelly]

Also add selectable pinned point process mode.

Discussion

This is some heavily work in progress (i.e. contains DEV_ASSERT(0) 😀 ) stuff for fixing the SoftBody problems introduced in #106863 .

Hopefully one of the SoftBody interested guys will take this all over as I'm keen to avoid any responsibilities in this area.

The difference between USER callbacks and engine callbacks.

I.e. PHYSICS_PROCESS and INTERNAL_PHYSICS_PROCESS, PROCESS versus PRE_FRAME_DRAW.

Users are restricted to calling things at certain times, engine developers on the other hand can use internal callbacks that can be assured to be after or before all user interactions. This is because a user might for example, move a bone, pin or whatever during a physics tick, or process, and we want to have rendering / physics react to that. (Users can use process priority, but the engine itself tends to separate user and internal into different phases).

This is commonly called "order of operations" and can cause a number of bugs, because moving one operation somewhere else can change the relative order, and create regressions elsewhere. This is notorious for causing problems, when a contributor is not aware of knock on effects.

Due to the chicken / egg effect, sometimes there is no option but to add a frame of delay.

Key things to note:

• There are some situations where it is better to update on the frame, some on the tick.
• Pinned points that are linked things that move on the tick make more sense to update on the tick (so the physics simulation is correct as possible). Pinned points that are linked to things that move on the frame (i.e. skeleton attachments) are more sensible to move on the frame, AFTER the engine and user has had the opportunity to move the skeleton.
• The rendering server doesn't need to be updated on any occasion except prior to rendering. It doesn't care what state the soft body is in during the physics tick.
• In some situations, two frames will occur with no physics tick in between. In this case, without physics interpolation there is no need to update the rendering server because the data is not dirty. With physics interpolation, you still need an update because the interpolation fraction will be different.

Notes

• Doesn't solve the existing threaded physics deadlock problem.

[Repiteo]

With the original issue being over a PR that's been reverted & lawnjelly noting they cannot dedicate time to this, we'll consider this PR more of a point-of-reference when revisiting a potential reintegration of interpolated SoftBody in 4.6