Use synchronous runtime for the main wasm execution lane

[joshua-spacetime]

Description of Changes

Before this change, we used a single async-enabled wasm runtime for all requests, even though procedures are the only operation that can yield. Now each module gets two separate runtimes. We continue to use the same async runtime for procedures, but now reducers are executed against a synchronous wasm runtime, backed by a single OS-thread instead of a Tokio runtime.

The purpose of this change is to remove from the critical path the overhead associated with async calls that really aren't async at all.

Also includes the following fix from #5135:

After #4973, WASM procedures can execute concurrently with later operations on the same WebSocket.

Before this change, the C# regression testsuite queued several procedures, then immediately queued UnsubscribeThen. After #4973, the unsubscribe could be applied before the SubscriptionEventOffset procedure callback ran, clearing MyTable from the local subscribed cache. The callback then failed while asserting that the offset-test: row was present.

This change treats unsubscribe as a separate phase. It is scheduled after the main work is queued, but only starts once waiting == 0, so all callbacks that inspect subscribed state run before the cache is cleared.

API and ABI breaking changes

None

Expected complexity level and risk

2.5

Testing

Pure refactor. Relies on current test coverage. #5078 will ensure the performance is on par with V8.