Apply additional fixes to servers' threading

[RandomShaper]

This is a follow-up of #90268 that ties up a few loose ends of it; namely:

• Startup and teardown of physics and rendering servers is know much more consistent among them and is better integrated with the new WorkerThreadPool-CommandQueueMT collaboration infrastructure.
• The DisplayServer stays unlocked in more conditions, which avoids ceratin cases of deadlock when input events are delivered.
• Post-draw callbacks and signals from the RenderingServer are now sent from the main thread. Otherwise, you'd for sure find dragons if using separate thread.

Not directly related, and so kept in separate commits, but their need found while working on this:

• OpenGL: Avoid error due to the assumption of the lifetime of the backbuffer texture being perfectly bond to that of the backbuffer FBO.
• ObjectDB: Properly lock the object database for cleanup.
• CommandQueueMT: Fix certain leaks when using separate thread for physics or rendering (thanks to @Zylann for the investigation). Also, properly handle resize of the command buffer!

Known issues (will fix the critical ones before changing from draft to ready-for-review):

• ~Windows, OpenGL: resizing windows using separate render thread deadlocks.~ FIXED
• Windows, Vulkan: resizing windows seems to apply some offset to the system surface. (Present in master. Will have its own PR.)
• MacOS: ~Can't test anymore since there's a crash.~ Resizing with Vulkan deadlocks. Possibly a MoltenVK issue. Reported (https://github.com/KhronosGroup/MoltenVK/issues/2213). ThIs PR can be merged despite it. If it turns out to be fixable in Godot, a separate PR can address it. UPDATE: Seems solvable at MoltenVK; in fact, I've submitted a PR there. *UPDATE: Fix merged upstream.

Fixes #89585. Likely fixes #90725 and #87382.

PS: A bit of testing on Linux with all the combos for rendering would be appreciated.

• --render-thread safe, --render-thread separate
• --rendering-method gl_compatibility, --rendering-method forward_plus