Drop the global lock around most of the Vulkan API commands

[Qining]

Unlock before calling the underlying API command calls, and lock again after
return from the underlying API command calls.

This improves the tracing performance, especially when the application
builds Vulkan pipelines in multiple threads.

[ben-clayton]

I strongly suspect this will break many things.
There are assumptions throughout the .api files and likely gapii that assumes there are no external changes to the state or encoders for the duration of a call.

We have considered adding an annotation to very specific commands in the API files which may unlock at the fence, but we need to spend a lot of time thoroughly checking these commands are unlock-safe, as well as the all the existing gapii code.

[AWoloszyn]

We have looked at this on the Vulkan side at least, and I think? everything is probably in good shape, but I agree just making the change across every call may be dangerous.

Qining, what about changing the annotation from @Blocking to @threadsafe (or something).
Since we know pipeline creation is one of the big ones, that can certainly help.

[Qining]

Annotation: "threadsafe" has been added to some of the Vulkan commands. Now we use "threadsafe" instead of "blocking" to control the unlock and relock behavior.

[ben-clayton]

shrug if you folks are sure that the rest of gapii is safe with this, then let's give it a try. I'm sure random crashes will alert us to any issues :)