Build gl separately for OFFSCREEN_FRAMEBUFFER

[kripken]

This lets a program use pthreads, but not OFFSCREEN_FRAMEBUFFER, and still work. Otherwise, the proxying code would have been reached anyhow, in the case that the context was created from JS. With this PR, it's not even linked in.

Note that I had to change some tests for this - do those look right?

[kripken]

Fixes a regression from #8059

[juj]

Perfect! Yeah reading through the changes I see that I had been working from the mindset that in multithreaded builds one would always be using either OffscreenCanvas or OffscreenFramebuffer, but naturally one can do without either, as long as one restricts GL to the main thread.

However I think before this PR things had worked well with GL-just-on-main-thread-with-use-pthreads case, due to the cases that had been tested had been using emscripten_webgl_create_context() API to create the context, with OffscreenFramebuffer being disabled - so the code would be getting the proxying machinery in, but always just not use proxying, since the proxying code is aware of the fact that proxying will not be needed if the GL context does actually live in the calling thread. In your case, I understand it was initializing the GL context in a way that avoided the proxying init somehow(?)

[kripken]

Yes, the code was creating the proxy in JS (using Browser.createContext etc.). It might be interesting to unify all the code paths for context creation, but it might not be good for code size, I'm not sure. But what this PR does seems optimal for that (no GL proxying code unless the user asks for it).