d3d11: Rework for concurrency model

Background

• ID3D11DeviceContext (drawing): not thread safe
• IDXGI* (swapchaining stuff): not thread safe
• ID3D11Device (resource management): thread safe

To protect concurrent d3d11 API call, we use GstGL like way, calling all d3d11 APIs from dedicated d3d11 device thread. The reason why I adopted "GstGL like concurrency model" was that user does not need to worry about the lock/unlock (everything would run from the dedicated thread) so it's deadlock free way. Note that d3d11 does not require the dedicated thread for d3d11 API call, but it's just thread unsafe.

Problem

DXGI call is deeply coupled with window procedure loop, and multi-threading might cause deadlock. See this section https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/d3d10-graphics-programming-guide-dxgi#multithread-considerations

In short, calling DXGI call out side of window procedure is deadlock-prone.

To avoid such annoying, presumably we can create window from the d3d11 device thread, but this quite not fit with our threading model. The worst case when we use a single thread for window procedure and d3d11 device thread is that, DispatchMessage call might not be returned depending on user input so the rest of d3d11 call would be never happen.

Another solution is that we might need to remove the d3d11 dedicated thread from d3d11device implementation and then we should introduce a single lock for d3d11device to protect, so that it can be called from any thread like window thread.