Adding Changes to Enable WASM-32 Support

[dagarcia7]

Summary of Changes

• Most of the changes needed to support a WASM build revolve around making the code async-friendly. As such, I added a wasm feature flag and added conditional rendering everywhere where async will be needed for WASM.
  • Note: because the there is a lot of code duplication as a result of this conditional compilation, I am monitoring @phklive's PR here https://github.com/0xPolygonMiden/miden-base/pull/725. When this PR is complete, I can change this approach to use the maybe-async-await macro as Paul-Henry has done in the miden-base repository.
• Aside from using the flag to support the async changes needed, I also used it to avoid compiling certain things like CLI files or SQLite store files that aren't needed for WASM.
• Finally, these changes trickled down to the Cargo.toml file where I tried to organize the dependencies based on whether the wasm feature flag and the target_arch is wasm32 or not.

Once this PR is accepted and merged, I will follow up with another PR to officially add the wasm crate. Once this is checked in, we can work together to publish the wasm code as an NPM package so others can start using it in their web applications.

[bobbinth]

Looks great! Thank you! Overall, I agree with the plan:

1. First, we'll merge #725 in miden-base. For this, @phklive will update the current implementation of winter-maybe-async macro and I'll publish the new crate.
2. Then, we'll update this PR to remove code duplication. After that we'll merge this PR. a. Here, would also be great to get rid of async_trait dependency.
3. Then, we'll merge #367 to clean up feature organization etc. a. For example, rather than having dedicated wasm feature, we might just have an async feature and gate all CLI-related dependencies behind the executable feature.
4. After these are done, we can add the WASM crate in a separate PR.

[bobbinth]

• First, we'll merge #725 in miden-base. For this, @phklive will update the current implementation of winter-maybe-async macro and I'll publish the new crate.
• Then, we'll update this PR to remove code duplication. After that we'll merge this PR. a. Here, would also be great to get rid of async_trait dependency.
• Then, we'll merge #367 to clean up feature organization etc. a. For example, rather than having dedicated wasm feature, we might just have an async feature and gate all CLI-related dependencies behind the executable feature.
• After these are done, we can add the WASM crate in a separate PR.

The first item from this list is now complete. @dagarcia7 - could you start on the second item?

[Dominik1999]

merge?