Multithreading 13/N: EGL in pthreads

[juj]

Rewrite EGL API as a C library to make it multithreading capable out of the box without needing to proxy.

This PR shows a different approach to getting APIs multithreaded, in comparison to #5532 and #5533. The advantage here is that it will not be necessary to do any proxying, but all EGL state is immediately shared, since it lives in the wasm heap instead of worker-local JS structures.

[dschuff]

So, caveat that I don't really know anything about EGL specifically, but I think this is the way we want to go where possible, because I think it will be the easiest to transition to the eventual wasm-threads (as opposed to workers) future.

[kripken]

Nice, I like how this builds on top of the HTML5 functionality.

[juj]

Migrating EGL from JS to C is still important direction. In this PR I did not have a chance to implement all the EGL features that the original library_egl.js had, so was uncomfortable landing it, and since this PR was posted, there have been new contributions to library_egl.js that make the gap a bit bigger. I'll close this PR as old, but the code in this PR could be used as a basis for a C-based EGL implementation if someone is interested. (Recently I migrated my 3D engine to use Emscripten HTML5 WebGL context initialization API instead of EGL, so EGL is no longer on a critical path)