Integrate asynchronous Aqua VM

[coder11]

Asynchronous version of Aqua VM is currently in development. It should be integrated into JS SDK.

Below is the description of the changes in AVM (copy-pasted here)

Guys, after fluencelabs/aquavm#130 the interpreter'll become async. It means that instead of sync waiting for a result in a call_service now the interpreter receives results in invoke export function.

The signature of call_serivce now looks as follows:

call_service(service_id: &str, fn_name: &str, args: &str, tetraplets: &str, call_id: u32)

The change here is an additional last parameter and no return results. This parameter represents id of call and should be used by host (node/client) later then to supply results into the interpreter while calling its invoke that now looks like this:

invoke(init_peer_id: String, air: String, prev_data: Vec<u8>, data: Vec<u8>, call_results: Vec<u8>) -> InterpreterOutcome

All is the same except an additional argument that should contain json-serialized HashMap<u32, CallServiceResult> . CallServiceResult is unchanged:

pub struct CallServiceResult {
    pub ret_code: i32,
    pub result: String,
}

After this PR a host behaviour should be changed also, now the interpreter could be called several times for each new current_data. Let's denote each such call as execution step. And the whole execution is completed if there were no call_service calls. More precisely, the interpreter flow inside a host could look in the following way:

1. for each new current_data received from a network, host should call invoke with corresponding prev_data and current_data and empty call_results
2. for each call_service a host should manage to match supplied call_id and computed service result. This computation could be either async or sync, it doesn't affect an interpreter (but affects resource consumption).
3. after finishing execution step, there could be non-empty next_peer_ids and it's a node duty to decide should it send particle after each interpreter call or after the its whole execution. But please note that host still must preserve new_data after each execution step.
4. If there were some call_service calls on step 2, a host must call the interpreter again with supplied call results (HashMap<u32, CallServiceResult>). Note, that current_data here shouldn't be supplied (actually, it could be supplied, but it's unnecessary and slow down a bit an interpreter execution). Then this flow should be repeated starting from point 2.
5. If there were no call_service calls step, the whole execution is completed, new_data must be preserved and particle send for new_peer_pks as usual.