[jspi] Require async js functions when used with __async decorator.

[brendandahl]

The _emval_await library function is marked _emval_await__async: true, but the js function is not async. With memory64 enabled we auto convert to bigint and look for the async keyword (which is missing) to apply the await before creating the BigInt. With my changes __async will require an async js function, which signals the function is used with JSPI and the appropriate awaits are then inserted.

Fixes #25468

[poretga99]

Can this PR proceed? We'd be more than happy if this landed in the main branch. We're currently patching released Emscripten manually.

[curiousdannii]

It's perfectly legitimate to return a promise instead, and sometimes that would result in cleaner code. This should be at most a warning, not a requirement.

[sbc100]

It's perfectly legitimate to return a promise instead, and sometimes that would result in cleaner code. This should be at most a warning, not a requirement.

Right, but there is no harm in doing both, right? async functions can do return somepromise just fine right?

[curiousdannii]

I guess.. though I think it would be slightly lower performance (probably not noticeable unless it's a really hot function.)

Hmm. If you did require async functions to be AsyncFunctions, then could you do away with the __async decorator?

[sbc100]

I guess.. though I think it would be slightly lower performance (probably not noticeable unless it's a really hot function.)

According to AI there is not any extra overhead: Returning a promise from an async function in JavaScript does not create a second promise in the sense of a new, distinct promise object being generated on top of the one you explicitly return. Instead, the async function's inherent promise-returning nature integrates with the promise you return.

Take that with as many grains of salt as you like ..