Optimize makeDynCall to avoid dynamic dynCall where possible

[sbc100]

Now the runtime dynCall is only used in places where the
signature is not known at compile time, such as embind or
(the internally unused) getFuncWrapper.

Followup to #12732

See: #12733

[juj]

Now the runtime dynCall is only used in places where the
signature is not known at compile time, such as embind or
(the internally unused) getFuncWrapper.

Move getDynCaller into embind.js which is the only place
it was used.

Hmm, while the above is is true for Emscripten code, what about external user JS code? Shouldn't we support the abstractions for general use, not just to enough to cover Emscripten API patterns?

[juj]

Also it looks like this will conflict with #12732, can that land first? (as it was posted first?)

[sbc100]

Also it looks like this will conflict with #12732, can that land first? (as it was posted first?)

Of course, this change was inspired by #12732, please go ahead and land that.

[sbc100]

Now the runtime dynCall is only used in places where the
signature is not known at compile time, such as embind or
(the internally unused) getFuncWrapper.
Move getDynCaller into embind.js which is the only place
it was used.

Hmm, while the above is is true for Emscripten code, what about external user JS code? Shouldn't we support the abstractions for general use, not just to enough to cover Emscripten API patterns?

This is an interesting point of discussion. I think there are two types of JS library functions that we might want to write but sadly I don't think have any way to distingish them today:

1. Function that are used internally in our JS libraries, which are subject to change at any time and not really designed for external libraries to use

2. Function who's interface we commit to and want to allow others to use.

In this case I'm not sure which type of function getDynCaller is. Regardless of the answer to that question I think it would be nice to be able to flag internal library functions that other libraries (especially external ones) are not exposed to.

[sbc100]

Looking more closely at getDynCaller, I only recently introduced it in #12059. And its location is not relevant to its visibility (sadly) so moving has not functional effect right?