vkr: relax big context lock

The entire vkr has been locked behind the big ctx->mutex since born. There are various kinds of lock contentions we have seen between the renderer main thread and the ring thread due to the big lock. After multiple timeline(!982 (merged)) and render server enforcement + rounds of server side cleanups(!993 (merged), !943 (merged), !973 (merged)), the lock is finally able to be relaxed in a reasonable way like in this MR.

A brief on the things implicitly protected behind the big ctx lock right before this MR:

• external synchronization for VkQueue between main thread submit_fence and ring thread Vulkan queue commands
• vkr_resource table access between main thread create_resource/import_resource/destroy_resource and ring thread CS/VkDeviceMemory
• vkr_object table access between main thread create_resource and ring thread CS
• ring list access between main thread destroy_resource(ring resource detach)/submit_cmd(ring create/destroy) and ring thread transport
  • ring notify can be expected to always go through renderer to be robust
  • ring write extra will soon be used to do inter-ring synchronization instead of only for roundtrip between renderer and ring
• CS stream resource access between main thread destroy_resource and ring thread transport
• CS fatal status propagation
• a single CS shared between ctx and ring cmd submissions

Then this MR handles them one by one and relaxes the ctx lock to the max extent in each step for clarifying the correlations.

Ps: this MR absorbs a refactor commit from https://gitlab.freedesktop.org/igor.torrente/virglrenderer/-/commits/Decouple_encoder_decoder, which was attempting to solve part of the issue. /cc @igor.torrente you might want to base your later experiments atop this MR instead ; )

Test:

• dEQP-VK
• vulkan apps
• venus-only ARCVM
• borealis dx and vk titles