feat: add abigen! macro

[glihm]

Here is the first draft for abigen! macro.

Issues

fixes #286
fixes #445

Usage

This macro aims at being used like:

// From a abi json file (path relative to Cargo.toml file).
abigen!(ContractName, "/path/abi.json");

// From a literal string containing the JSON. This one was more used for
// testing, perhaps not useful.
abigen!(ContractName, r#"
[{...}]
"#);

Code organization

The code is separated in 3 parts:

1. cairo_types which contains the mapping of Cairo native types into rust types.
2. parser contains all the logic to parse ABI as a JSON, where types are strings, and totally flatten. This is where the generic types are detected and applied to each member/variant or struct/enum.
3. abigen contains the code logic related to macro expansion and code generation.

Examples

Two examples were added:

1. abigen.rs contains the very basic usage working on testnet with user addresses.
2. abigen_event.rs shows how abigen! facilitate the deserialization of events.

[glihm]

Just seen that ConnectedAccount trait offers a method to get the provider from the account.

Maybe we want two ways of initialize the contract:

// For calls only.
let contract = MyContract::new(address, provider);

// For invoke and calls.
let contract = MyContract::new_with_account(address, account);

And internally, we use the provider if present in case 1, or the one from the account in case 2.
Perhaps this will be easier for init. To be checked with Pia (can't tag here right now) as she working on the with_account design.

*** EDIT ***
reworked to now generate MyContract and MyContractReader. Having the reader included inside the MyContract implementation which is the one with account.

[glihm]

@xJonathanLEI let me know when you would have time for a first review, in order to keep going forward with this feature. 👍

I am exploring a new version where every interface in the ABI is implemented in a trait, this IMO can be helpful to easily switch targeted contracts without changing the actual code using them.

[glihm]

Other idea that may be interesting, we can add some option for the code generation. For instance, it can be useful sometimes to get access to the Call generated by an external, without sending the transaction. This can help when we only want to send one transaction, with several calls inside it.

[Eikix]

Hey:)! At Kakarot, we're super interested in such a feature, any ETA or reason why it shouldn't more forward for now?

[glihm]

Hey:)! At Kakarot, we're super interested in such a feature, any ETA or reason why it shouldn't more forward for now?

Hey! Currently re-working the code to enhance the proposal in this PR using Syn crate to parse types and enhancing devX following alloy nomenclature.

This will allow more flexibility on configuration for the calls and invokes.