asynchronous IO

[Geal]

currently, TCP connections are blocking (ie, they block the whole interpreter). To have a server that handles reasonable load, we might need to have blocking IO on the wasm side, that translates to async IO on the host side.
This is doable if we have a way to pause the interpreter (see wasmi-labs/wasmi#85) and start again once we get an event on the socket.

[Geal]

with fb872b7 we have the beginning to get async IO working.
The idea would be to handle a special case in function calls:
fb872b7#diff-6819af94d9e962b4dc7ef16cb532e1f2R68

In the case of external function call (ie not the nested case), if the function is asynchronous, it would return a custom error (a "trap") from invoke_context( fb872b7#diff-6819af94d9e962b4dc7ef16cb532e1f2R66 ), and then the interpreter would keep the function stack and the function context instead of returning an error, and when we finally get the answer, we would update the context and then resume the interpreter