Wasm32 support

[tdelabro]

wasm support

Description

This pr introduces wasm support for cairo-rs. Aka a new compilation target.
It also adds the std feature, present by default. And the possibility to remove it to compile a slightly different no_std binary

[Oppen]

Hi @tdelabro. Overall it looks good. I left a few comments and questions tho, let me know what you think.

[codecov]

Codecov Report

Merging #828 (ed77a3f) into main (91bd6b0) will decrease coverage by 0.06%.
The diff coverage is 87.98%.

@@            Coverage Diff             @@
##             main     #828      +/-   ##
==========================================
- Coverage   97.47%   97.42%   -0.06%     
==========================================
  Files          69       69              
  Lines       29049    29120      +71     
==========================================
+ Hits        28315    28369      +54     
- Misses        734      751      +17     

Impacted Files	Coverage Δ
cairo-vm-cli/src/main.rs	25.53% <0.00%> (ø)
...t_processor/builtin_hint_processor/blake2s_hash.rs	100.00% <ø> (ø)
..._processor/builtin_hint_processor/blake2s_utils.rs	99.74% <ø> (ø)
...int_processor/builtin_hint_processor_definition.rs	98.69% <ø> (ø)
...uiltin_hint_processor/cairo_keccak/keccak_hints.rs	93.91% <ø> (ø)
...rocessor/builtin_hint_processor/dict_hint_utils.rs	99.23% <ø> (+<0.01%)	⬆️
...t_processor/builtin_hint_processor/dict_manager.rs	96.73% <ø> (ø)
...int_processor/builtin_hint_processor/hint_utils.rs	94.59% <ø> (ø)
...t_processor/builtin_hint_processor/keccak_utils.rs	100.00% <ø> (ø)
...int_processor/builtin_hint_processor/math_utils.rs	97.95% <ø> (-0.01%)	⬇️
... and 64 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[Oppen]

Besides the other comments, an important question. Is the wasm version expected to generate traces or just execute and retrieve the output? If it's the latter, we can keep a sizable chunk of the code as is (specially the parts that would use much more memory) by just avoiding compiling them for nostd.

[Oppen]

Also, this PR is a breaking change, it require you to add the feature std to your import in order to stay iso functional.
Should we increase the semantic versioning accordingly?

That's up to you. Versions of the form 0.x.y are free to break APIs at any point without bumping minors or majors according to the semver specification. Just don't bump it to 1.x.y.

[tdelabro]

Maybe core::fmt::Write could be enough? Or simply including conditionally that or the one in std::io::Write depending on whether or not we use std.

I picked core::fmt::Write. Conditionally using one or the other was more annoying than anything because types like Sting implement only the core one, one the io

[tdelabro]

Besides the other comments, an important question. Is the wasm version expected to generate traces or just execute and retrieve the output? If it's the latter, we can keep a sizable chunk of the code as is (specially the parts that would use much more memory) by just avoiding compiling them for nostd.

I think we do. Imagine running a program in the user browser, generating the trace, sending it to the verifier, and getting the proof back. All in a web app, only running on the user's machine

[tdelabro]

@Oppen @Jrigada I think it is ready for a new review and maybe a merge

[Oppen]

Last round of changes and it's done.
Please don't use git commit --amend or git rebase. We'll squash it on merge so it doesn't make a difference history-wise and it breaks GitHub making it impossible to see changes from the last review. This means reviewers need to go through all the changes again to find what changed.

[Oppen]

🎉 🎉 🎉

[fmoletta]

LGTM, Thanks!!