wasm-micro-runtime: TSAN fast interpreter failure

But exception may be thrown when calling the import or start function, and the exception may haven’t been prorogated to the original module_inst, we had better set it before switching exec->module_inst back into the original module_inst, like current handling in wasm_interp_call_func_import: https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/interpreter/wasm_interp_classic.c#L1040-L1046

these functions propagate an exception via the return value. while we should propagate it to the original module_inst at least for the purpose of wasm_runtime_terminate, i’m not sure if it’s appropriate for existing users of the api. i need to think about it a bit more. (thus the PR is a draft)

This seems to be because that before creating a new thread, runtime will instantiate the module instance for it (and do the instantiation in the parent thread), and at the end of instantiating, runtime executes the start of the module, and to make the exec_env consistent with the exec_envs in the parent thread’s call stack, runtime temporarily replace exec_env->module_inst with the child module instance.

There may be two options: (1) since the start function has been called in the main thread in the first time instantiation, we don’t call it again in the later instantiation, (2) add cluster->lock for replacing exec_env->module_inst, executing start and restoring the exec_env->module_inst in the later instantiation.

@yamt how do think?