Solana: Execute proposal (only transfer)

[GuidoDipietro]

Implements execute_proposal on SVM Settler, only for transfer intents.
In tandem with this PR.

Almost 50% of this PR's additions are Cargo.lock., and the remaining 50% is 58% unit tests.

---

New dependencies

anchor-spl was added to the Settler program since we are now performing SPL transfers (token transfers).

A note on SPL token "approvals"

Solana has a similar mechanism to EVM's approvals to move tokens on behalf of another wallet. This is called "delegate". You can design a delegate and a delegated amount to a given token account, which works as expected (the delegate can transfer up to "delegated amount" tokens, in one or more transactions).

The proposed implementation uses a PDA delegate (i.e. an account owned by the Settler program), so that users can give approval "to the Settler" or "to the Protocol" by adding this PDA as the delegate for their token accounts.

A note on style

Some lines are split into multiple ones, making readability of the Settler code a bit harder. I think we would benefit from extending the max line length, but doing so in this PR will imply making review harder, so let's keep it for another one.

A note on remaining accounts

The so-called "remaining accounts" are the AccountInfos not parsed by any Anchor macro. These accounts are equivalent to how "vanilla" Solana programs work, where you just receive an array of AccountInfos and it is your responsibility to properly deserialize and check them.

Anchor does a ton of this work for us in their Accounts struct (tagged with #[derive(Accounts)]), but this comes with some limitations. One of them is that we can't pass dynamic accounts. Since the nature of the accounts struct in this instruction is dynamic (given the intent's operations, in this case transfers, is dynamic as well), we need to resort to "remaining accounts" and do everything by hand.

The SvmSettler SDK will include a method to calculate these remaining accounts so that it remains transparent to the SDK user, as it should be given this is only a technical aspect of the implementation. This is missing in this PR as it will be added on the implementation on the Solver to avoid PR clutter.

Expected remaining accounts

The execute_proposal expects the following remaining accounts for a transfer intent, in this order:

• Token Program
• Token 2022 Program
• For each transfer:
  • Transfer token mint
  • Transfer recipient
  • Recipient transfer token account
  • User transfer token account
• For each proposal fee:
  • Fee token mint
  • Solver fee token account
  • User fee token account

The minimum number of remaining accounts for an intent with one transfer and one fee is 9 accounts.
I have decided to simply list every account, even if some might be repeated (such as, if fee token == transfer token, we will have 2 repeated accounts). This approach is simpler on the Settler code, although it might lead to us reaching accounts constraints more quickly (~64 accounts max on legacy format).

I propose that we go with this design and modify it afterwards if we find it necessary (an easy solution is using v0 transactions, which would be a quick fix).

---

Tests will remain to fail on CI until SDK version is bumped. PR merges are halted as main has changed significantly, until end-to-end is tested and we see that it works fine.