build: initial cargo workspace and build pipeline

[gregorydemay]

(XC-280): Basic skeleton of a Cargo workspace and build pipeline:

1. The Cargo workspace is organized in 4 crates:
   1. The sol_rpc_canister crate is a binary crate that will contain the canister code.
   2. The sol_rpc_types crate is a library that will contain all Candid types used by the Candid interface of the canister. This is to potentially allow developers to easily write their own client.
   3. The sol_rpc_client crate is a library that will contain the client code to interact with the canister. This will be the main entry point for most developers.
   4. The sol_rpc_int_tests is a crate that will contain integration tests using PocketIC to test both the canister code directly or the client.
2. The build pipeline has the following stages:
   1. Ensure that the PR title adheres to conventional commits.
   2. Linting with the Rust formatter and clippy
   3. Building the productive wasm by reproducible build. This step is currently done only with cargo instead of Docker and is actually not reproducible. This will be addressed in a future PR (XC-283).
   4. Running the unit tests.
   5. Running the integration tests with PocketIC using the wasm produced by the reproducible stage.

[lpahlavi]

Overall LGTM! Two questions/comments:

1. Do you have a particular reason for deviating from the overall structure of the evm-rpc-canister repository (e.g. no top-level src directory), or is it just a matter of taste?
2. Could you maybe also add the License and Changelog files? This can also come later.

[gregorydemay]

Thanks @lpahlavi for the review!

1. Do you have a particular reason for deviating from the overall structure of the evm-rpc-canister repository (e.g. no top-level src directory), or is it just a matter of taste?

It's mostly a matter of taste. Why I chose the current structure:

1. It's important to cleanly separate anything related to the canister from the libraries. In the EVM RPC canister, there are many files (dfx.json, canister_ids.json, etc) that are top-level in the repo but are only actually relevant for the canister. It's also because here the types library came afterwards.
2. I want to separate the integration tests from the other types of tests to ensure that they use the productive wasm (the one that will be built by the reproducible build job)

2. Could you maybe also add the License and Changelog files? This can also come later.

Good idea. I will add licences and a README for the relevant crates. Changelog I will keep out for now because ideally I would like to have it generated (see XC-284). Since the changelog files need to also be referenced in the Cargo.toml I added a basic skeleton to avoid forgetting them. PTAL.

[lpahlavi]

Thanks for the explanation regarding the overall structure and for adding the licenses and READMEs, LGTM!