Add cairo1 compilers

[ericnordelo]

This PR enables Nile to compile Cairo1 contracts, generating the corresponding .sierra and .casm artifacts (alongside the extracted ABI).

It is drafted for the reasons listed below:

1. The Cairo1 compilers are not published to crates.io yet, so as a temporary solution, the binary files were added to the project for testing purposes (compiled for macOS platform). We should update this approach to use the locally installed version after the package gets published.
2. For the previous reason, tests have not been added to the repository yet (only manual tests have been executed).
3. The PR is exposing the Cairo1 compilation through a compile-1 command in the CLI. This design was implemented just for testing purposes. We still need to define the API to expose both Cairo1 and Cairo0 compilers in the transition period (with starknet 0.11).
4. From the fact that we can't directly manage dependency versions for the rust compiler (after published) in Nile (being a python project), I think we should implement a rust crate as a proxy, so we can control what version of the rust compiler Nile will be using, by making it dependant of this crate instead of the compiler directly. If we don't do this, changes in the compiler API can break the Nile integration.

How to test this branch:

• Checkout to it and run pip install .
• Copy this hello_starknet.cairo contract as an example inside the contracts directory (or any other directory as you would do with the current compile command).
• Run nile compile-1 contracts/hello_starknet.cairo to compile it (or change the path accordingly).
• Check the artifacts inside the artifacts/cairo1 directory (including sierra, casm and abi).

Note that if you are not in macOS, you may need to re-compile the compilers and update them for your platform (in linux this is perhaps not required).

[martriay]

• We still need to define the API to expose both Cairo1 and Cairo0 compilers in the transition period (with starknet 0.11).

Do we? I'm assuming there will be no projects using Cairo0 (c0 for short) and c1 simultaneously. If so, nile 0.13 should be enough for c0 projects, no? And we can remove the cairo-lang python dependency, although that would require a full rewrite of nile as well given how much it relies in c0 python modules.

[martriay]

direction looks good! my main concern is that we might have to find a way to make nile work nicely with rust.

not sure if we should go for a full refactor in Rust, or simply distribute Nile as a binary/executable without requiring a venv nor pip install that adapts to the new starknet CLI (or Rust modules that replace the current CLI nile depends on)

[martriay]

i think we can remove this file and just replace variables in good ol' common/ if we drop Cairo0 support

[ericnordelo]

Do we? I'm assuming there will be no projects using Cairo0 (c0 for short) and c1 simultaneously. If so, nile 0.13 should be enough for c0 projects, no?

Right. Then we can keep the same API.

And we can remove the cairo-lang python dependency, although that would require a full rewrite of nile as well given how much it relies in c0 python modules.

Exactly, and being this rewrite probably a considerable effort, I'm leaning toward going for the full refactor in Rust. The main blocker I recognize for this is the stage of the cairo repository itself (documentation and features for starknet), but maybe is currently enough to replicate nile without re-implementing a lot? Should we work in parallel on python and rust versions already?

or simply distribute Nile as a binary/executable without requiring a venv nor pip install that adapts to the new starknet CLI (or Rust modules that replace the current CLI nile depends on)

I think (from thinking quickly) this won't be considerably easier than reimplementing in Rust, so for long-term consistency, I would go for the full refactor. But I'm not sure how much effort will this take, from the current status of the cairo repository.