Investigate using WASM

[Wodann]

We're investigating WASM as an alternative of our native Node.js package, created using N-API. This mainly provides two added benefits:

• browser support
• ease of maintainability due to more mature support for tooling (as it's backed by a larger community than N-API)

There are still some concerns about feasibility in EDR's use case that would need to be investigated:

1. support for background threads; since we're currently using (dependencies that rely on) the tokio runtime
2. async APIs
3. composability of a "core" EDR component alongside third-party components that reuse types from the "core" EDR component; to allow for our multi-chain design of "one package per chain type"
4. overhead of FFI / marshalling of memory
5. general memory and runtime performance; given that we'll transition from native binaries to interpreted WASM
6. backwards compatibility of porting over existing N-API interface. Given the high amount of users on Hardhat, very slight changes in API behaviour (w.r.t. undefined fields, nulls, ordering, etc) inherent to N-API, but slightly different in WASM could cause subtle bugs.
   Some helpful references materials that can be used during the exploration:

• https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md
• https://github.com/bytecodealliance/jco
• https://component-model.bytecodealliance.org/design/wit.html

Definition of Done
A concrete plan for adopting WASM as an alternative or alongside our N-API interface, if possible. The plan should find answers to all aforementioned concerns