d3d11: Rework for concurrency model
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.
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.