glapi: Support "ELF" TLS on Windows
To avoid a massive rename, I'm leaving this as a misnomer, it's not really ELF TLS, but it's the same concept.
Note that Windows doesn't support thread-local variables imported or exported between modules, so we can only support this when we're not using a shared glapi. At least, if I understand which component is responsible for what, that's the case.
This fixes #4050 (closed) (at least for Dolphin). Dolphin's bug was caused by the following pattern:
- Thread A binds a context and issues rendering
- Thread B attempts to bind an invalid context
- This ends up unbinding the framebuffer from the (currently-global) context that was originally set by A, because the "is this app multithreaded" logic hadn't kicked in yet.
- Thread A issues a SwapBuffers
- This should flush the rendering work from the first step, but doesn't, because the framebuffer (window) being swapped doesn't match the current context's framebuffer, because of the bug in the second step
- The context is actually flushed later on
- This submits the first step's rendering work to D3D, which references the resource that was the back buffer during the first step, but is now the front buffer after the third step. This violates a rule and puts the D3D device into a bad state, at which point future commands will fail.
By adjusting step 2 so that it doesn't affect thread A's currently-bound context, the bug is fixed. This also would have a side benefit of increasing performance by embedding the TLS offset for the GL context/dispatch table directly in the code, instead of storing the address of the TLS offset which needs to be loaded every time.
I suspect this was broken by !7280 (merged). /cc @kusma @idr @lfrb