Fix possible data races between the main and GL threads

[gonetz]

opengl_Wrapper.h / .cpp — m_swapBuffersQueued → std::atomic

The counter was incremented from the main thread (SwapBuffers) and decremented from the GL command thread (ReduceSwapBuffersQueued), with no synchronization between the two writes. That's a data race — undefined behavior in C++. std::atomic makes every read/write an atomic operation; the existing ++, --, and comparison operators all work unchanged.

glsl_CombinerProgramBuilder.h / .cpp — s_cycleType and s_textureConvert → thread_local

These were plain static class members set at the top of buildCombinerProgram and then read throughout all the _write* sub-functions. If two threads ever call buildCombinerProgram concurrently, one would stomp the other's values mid-build, corrupting shader generation. Changing them to thread_local gives each thread its own copy, so concurrent builds are isolated. No call-site changes needed — all the existing CombinerProgramBuilder::s_cycleType reads throughout the Accurate and Fast builder files automatically pick up the correct per-thread value.

[gonetz]

@fzurita please review

[fzurita]

Yes, first issue is a real issue. Second issue with the static variables, I think that is unlikely to be triggered since I think we only ever have a single thread calling buildCombinerProgram if I recall correctly? Either way, I don't think it would hurt anything to make them local.

[gonetz]

Good, thanks!
I'll merge it then.