Draft: opengl: refactor API to provide execution context

Disclaimer: the work is not finished yet. OpenGL providers like EGL need the addition of a thread. The new API is not pretty yet and a lot could be factored together. The clients are not using the new API. The old API still exists though some providers cannot implement it. The Core animation macosx display has not been ported too, but we might just remove it if needed. The EGL code is also not behaving correctly for Swap() because the context is not current. OSX should enable HAVE_GL from the configure.ac.

---

This merge request brings the last part to unify every OpenGL implementation in the tree and future ones.

OpenGL contexts providers are dependant on their execution context. Most implementations are capable of executing code from any thread as long as the context is made current to the thread and only this thread. However, it can have consequences like VSYNC being applied multiple times (see #23566 for instqnce).

Some other implementations strongly require that the code is executed from the correct thread, or even stronger for the web typically, the correct process-like.

Still, OpenGL clients expect to be able to signal when a new frame needs to be drawn and when a new rendered frame needs to be presented.

By providing a way for the OpenGL provider to control the execution context, we can be compatible with every possible context and use client code like opengl/display.c for every provider.