Can't create new Wasm Execution Contexts while another thread is running an existing Execution Context

[gzurl]

Describe the bug

In execution_ctx.rs run() method, the WASM_RUNTIME_EXECUTIONCTXS hash map is locked as read() during the Wasm module execution.

This means new threads (new HTTP incoming requests) can't create new execution contexts since that would require exclusive write() access.

In a 'normal' scenario, this is suboptimal because it might lead to a situation where Apache is allocating more resources than mod_wasm can leverage.

But in an adverse scenario, if a Wasm module execution takes longer than usual (or hangs up), that might block other incoming requests.

Since CPU-limited executions are not implemented yet (see #9), it would be much better to ensure that the WASM_RUNTIME_EXECUTIONCTXS hash map is not locked at all during the Wasm module execution.

Reproduction steps

1. Create a configuration with two different locations:
   • a) /intense_task, whose Wasm execution takes a long time (ie: 10secs)
   • b) /light_task, a very simple and immediate task
2. Start up Apache and check both locations works as expected.
3. Then load /intense_task, and right after, try loading /light_task: It should be obvious that such /light_task won't start until /intense_task is done.

Expected behavior

In a mono-thread scenario (ie.: httpd -X), new requests are queued and dispatched one by one.
In a multi-threading scenario, new requests shouldn't be delayed because other requests are running the Wasm module.

Additional context

This issue was reported by @juamedgod, who noticed a wrong behavior while testing a dev version of PHP.wasm whose execution never finished. Thanks for reporting!!