Support wasm

[danielgranhao]

Resolves #90.

This PR:

• Changes the http client from ureq to async reqwest
• Switches to a different secp256k1-zkp fork that circumvents wasm compatibility issues
• Changes the websocket crate from tungstenite to tokio-tungstenite-wasm - as the name indicates, this crate uses tokio-tungstenite for native builds
• Adds esplora as a supported chain data backend. Electrum is still supported. Both can be enabled using features, allowing clients to switch backends at runtime (which may be useful for redundancy). Only esplora is set as a default so that wasm is supported by default.
• Allows reusing esplora and electrum clients instead of having to create new ones on every method.

There are still some TODOs, but I would appreciate some initial feedback.

TODO:

• Testing (adding new tests for esplora + run ignored tests)
  • I've made the testnet and mainnet integration tests run against regtest and added regtest as a submodule. These tests now run in CI both on native and wasm builds.
• Try to upstream changes to secp256k1-zkp
  • I've rebased sanket's PR (on which we depended already) on top of the secp256k1-zkp main branch (to pull in a WASM fix) and added an additional workaround/fix on top. I won't be trying to upstream the changes because his PR has been dropped in favor of adding musig2 support on the base secp256k1 crate (WIP here). Hopefully soon a fork won't be needed any longer.

[roeierez]

Passing a config forces this function to call build_client (and create a new client) which prevents from the caller to reuse a client implementation. In electrum we have seen it has a big performance penalty.
I know this was the implementation before this PR but perhaps if we are going for such a big change we can improve it?
I commented on this method as an example but this pattern repeats itself.

[danielgranhao]

Thanks @roeierez. I agree. I've made the methods take a client instead of the config in a6d9d1c