Move emscripten_GetProcAddress callers into C

[kripken]

This avoids having them on the right-hand-side in deps_info, which
means that in REVERSE_DEPS=all mode we do not include that
function and all the GL code it calls. Instead, the callers are just more
C functions that the linker does the right thing.

[sbc100]

Awesome!!

[sbc100]

Would it not make sense to these to live in their various different libraries?

Is emscripten_GetProcAddress just for GL symbols? I wonder if it should be renamed to reflect that?

[kripken]

We don't have compiled libraries for them, and adding new ones just for what are basically aliases seemed like overkill. Perhaps we can even just make them aliases in the headers, if you prefer that?

Yes, that function is just for GL symbols. I'm not opposed to renaming it (separate from this PR I assume?)

[sbc100]

I'm fine with this now if tests pass.

[sbc100]

Can we also do the same for emscripten_GetAlProcAddress callers?

When those entries removed too the vast majority of the effect of REVERSE_DEPS=auto is just the size of dlmalloc/dlfree.

-rw-r----- 1 sbc primarygroup 123323 Feb 23 19:36 all.js
-rwxr-x--- 1 sbc primarygroup  14801 Feb 23 19:36 all.wasm
-rw-r----- 1 sbc primarygroup 120058 Feb 23 19:36 auto.js
-rwxr-x--- 1 sbc primarygroup    790 Feb 23 19:36 auto.wasm

JS size hardly effected and wasm size goes up by ~10k which is basically the cost of malloc/free:

 - func[29] size=6095 <dlmalloc>
 - func[30] size=1732 <dlfree>
 - func[31] size=134 <dlrealloc>
 - func[32] size=1015 <try_realloc_chunk>
 - func[33] size=23 <dlmemalign>
 - func[34] size=412 <internal_memalign>
 - func[35] size=1661 <dispose_chunk>

[kripken]

@sbc100 Yes, I think those can be done as well. Do you prefer them in this PR or in another?

But ping on my questions from earlier, this PR is waiting on a response from you there I believe? (#13524 (comment))

[sbc100]

Followup PR is fine.

[kripken]

Looks like tests failed due to SDL2 linking in its own SDL_GL_GetProcAddress. I made the symbol weak to avoid that - thoughts?

[sbc100]

Making it weak sounds fine. Another alternative might be to put each function in its own object file.. but that might cause complications with --whole-archive users.