EGL multi-context support, and other ideas
It seems like the EGL loader could really benefit from multi-context support. With EGL 1.5, or with [EGL_EXT_client_extensions](https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_client_extensions.txt), different extensions are made available without and with an `EGLDisplay`, i.e. client vs display extensions respectively. I found that in my code I was forced to re-load the context any time I needed to switch back and forth between the two, which is a bit cumbersome.

I've been maintaining my own fork of glad2 to better handle this. My changes are almost certainly not ready to merge as-is, because I only really use glad2 with these arguments:
```
glad --out-path="$PWD" --api gl:core,gles2,vulkan,egl,glx,wgl --merge c --alias --loader --mx --mx-global
```

So there's a high chance that my changes break other argument combinations, or tests, in some way. (Also I had to restore the `--mx-global` feature, I'm not sure why that's [gone](https://github.com/Dav1dde/glad/commit/cf4badba596a555ef92003dc2c0c5edfc5934b2a) in the glad2 branch right now?)

Regardless of the quality of my changes (man, that templating stuff is a headache), I'd like to share these changes with you in case you can get them into better shape!

https://github.com/tycho/glad/commit/f0a1597f5125b6b7e0805ce1108b3ac146f5133e Allow loading with `EGL_NO_DISPLAY` (to get client extensions), and do not implicitly get the current `EGLDisplay` when `EGL_NO_DISPLAY` is passed
https://github.com/tycho/glad/commit/10c9b1d52376a7056a81595da165ef35e242cc4a EGL multi-context support

And this change is less relevant to this specific problem, but maybe worth review anyway:

https://github.com/tycho/glad/commit/ba3c786f5f32ce562a327c5b14894955577e8f17 Implement plain C API function declarations as MSVC IntelliSense hints, because the global context macro definitions don't give any source-level hints for arguments. This change allows Visual Studio to do this:
![image](https://user-images.githubusercontent.com/29616/199534970-431c6df0-b29f-4308-a8ea-5d4e1e55920f.png)

Anyway, the multi-context support for EGL can be used in practice something like this:

```cpp
GladEGLContext s_contextEGL[2];
[...]
gladSetEGLContext(&s_contextEGL[0]);
gladLoadEGL(EGL_NO_DISPLAY, (GLADloadfunc)SDL_EGL_GetProcAddress);
gladSetEGLContext(&s_contextEGL[1]);
gladLoadEGL(eglDisplay, (GLADloadfunc)SDL_EGL_GetProcAddress);
```
So the context at index 0 includes the supported client extensions, while index 1 contains the supported display extensions.

As I'm writing this, I had an afterthought that maybe an alternative to doing this (and possibly a more usable one) would be to make the EGL loader discover the client and display extensions at the same time. That is, if `EGL_NO_DISPLAY` is provided, only discover client extensions, and if a real `EGLDisplay` handle is provided, do one pass to discover client extensions via `EGL_NO_DISPLAY` and then do a second pass to discover display extensions with the provided `EGLDisplay`, and store both of them within the same `GladEGLContext` structure.