Potential optimization for imported async functions

[cpetig]

Exported async functions have been changed in November to receive their arguments on the value stack, so these function calls now impose less overhead.

Imported async functions on the other hand still use a heap allocated list to pass arguments. While this is motivated by minimal overhead for back-pressure it penalizes the common case of async function calls with few parameters, e.g. a string or list. The overhead to store the arguments on the host in the (less likely?) back-pressure case could be acceptable in comparison to this unconditional heap allocation on the client side.

When I brought this up in bytecodealliance/wit-bindgen#1082 (comment) Joel proposed to open discussion here.

[lukewagner]

(Sorry for the slow reply; getting back from holidays) Currently, if there is only one flattened parameter, it is passed as a scalar instead of going through linear memory (see flatten_functype). So, one option we have is to relax increase this max-async-flat-parameters limit from 1 to something a bit bigger.

We do have to be a little careful since increasing this limit will increase the static size of the engine-internal structure used to represent async calls to have space for the maximum number of async flattened parameters. But maybe a modest increase to, say, "4" would be reasonable? It'd be nice to have performance data to motivate this, though.

[lukewagner]

Proposed in #520.