Fix Vulkan multithreaded compute list and GPU particle processing

[bitsawer]

• Fixes Vulkan: GPUParticles3D crash when duplicating 128 at once #70607
• Fixes GPUParticles3D crash with Z-Billboard after creating certain number of instances #78498
• Maybe fixes Vulkan: "Uniforms were never supplied for set(3)" error causing very noticeable artifacts #77759, but there is no test project so hard to say for sure.

Possibly helps with some other existing issues too, anything that uses compute shaders and threads can be affected.

Best test project to test this is probably this one: #70607 (comment) The project has a nice, big button that seems to trigger this bug every time.

The issue is that under heavy load, the multithreaded scene culling sometimes ends up calling RenderingDeviceVulkan::compute_list_begin() quickly in multiple threads when dealing with particles etc. This should be fine, but the actual bug is that the lock (_THREAD_SAFE_LOCK_) was taken too late, only after the error checks. This causes some threads processing particles to simply fail instead of simply waiting their turn before doing those error checks. This PR adds _THREAD_SAFE_METHOD_ to make sure the other threads wait their turn properly before proceeding.

Usually, the code fails here: https://github.com/godotengine/godot/blob/6588a4a29af1621086feac0117d5d4d37af957fd/servers/rendering/renderer_rd/storage_rd/particles_storage.cpp#L1210C3-L1210C3 as the processing code is run in a multiple WorkerThreadPool threads at the same time.

This continues the somewhat piecemeal fashion of adding thread thread safety into the Vulkan rendering device similar to #79526, not sure if these should also ported to the Direct3D 12 PR eventually.

[clayjohn]

One more mutex for the pile...

Let's merge this for now. It will help us identify problematic functions when we overhaul the multithreading functionality

[YuriSizov]

Thanks!

[YuriSizov]

Cherry-picked for 4.1.3.