Add moonlight transactions

[ureeves]

execution-core: add Moonlight and rework withdrawals

With this commit we add MoonlightTransaction, and rename the existing
transaction to PhoenixTransaction, both of which are incorporated into
an enum named Transaction.

We also rework the withdrawals system, under the assumption that there
must be a strong assurance that the transacting party own the addresses
being withdraw to. This enables cross-withdrawals from Moonlight to
Phoenix (and vice-versa), as well as withdrawals to the same transaction
model.

The liberty is taken to change the stake data structures slighty, to
improve on clarity, as well as make use of the new withdrawal system.

transfer-contract: support for moonlight and expanded withdrawals

We add support for Moonlight transactions by adding a map between public
keys and their respective account data as defined by execution-core.
This means also adding a query function for this account data - named
account, taking as argument a public key.

Support for the new withdrawal system is also added, in a way that we
can reuse code between withdraw and mint, effectively minimizing the
amount of code written. One downside of this new system is that
contracts are no longer able to set data in the Sender of a Phoenix
note. Instead the tranfer contract is responsible for setting it, and
currently we set the contract ID withdrawn from, together with a
suffixed string.

We take the liberty to rework the transient data held during a call ray,
effectively minimizing data being passed back and forth - for instance
during a refund call. We also rename balance to contract_balance
contract-wide, to avoid confusion with Moonlight accounts.

stake-contract: rework to use new withdrawal system

We rework the contract to make use of the changed data structures. Most
notably, mint and withdraw now make use of the new withdrawals
system.

rusk-recovery: change to handle moonlight on genesis

To handle placing moonlight balances during state recovery, we add a new
moonlight_account item than a .toml configuration file can specify a
balance for given accounts at genesis. To ensure clarity we also rename
the balance item to phoenix_balance.

rusk: support Moonlight transactions

To support Moonlight transactions, we leverage the changes made to
execution-core to unify the handling of both transaction models using
the exact same code path as before.

Resolves: #1723, #1856
Closes: #1812

[fed-franz]

I just reviewed the changes to consensus for now. I'll review the ones related to moonlight in another moment.

If I may, I'd suggest splitting the PR when it gets this big and there are "unrelated" changes. For instance, in this case, it would have helped having a PR with the changes to consensus, and then one based on the previous PR's branch with the moonlight changes.
This is just a suggestion to ease (and actually improving) the reviewing process in the future.

[ureeves]

@herr-seppia, @fed-franz, @vlopes11 and I had a short meeting, and we all agreed the scope of the PR is far too large, and that the changes in the consensus that it introduces are wrong. To address this I'm setting the PR as being a draft while taking the changes targeting the consensus out.
Will remark as ready once done

[ureeves]

Alright. I've removed the stake changes, and addressed all comments that were already made. I'm reopening this for review once more.

[moCello]

Generally really nice work!
Apart from some minor nits, I do want to raise the naming and creation of new structs.

• There are two Withdraw structs (one in the stake and one in the transfer module of execution-core) which to me is highly confusing. If they serve different purposed, this should be reflected in their names as well, otherwise the stake contract can use the Withdraw from the transfer module.
• Another point is the introduction of the two WithdrawPayload and the StakePayload structs. What is the reason why the structs exist? Previously the fields of the now ...Payload structs were part of the bigger struct. To me adding different payloads for different contexts (especially when there are two different Withdraw structs) is very confusing as I always have to look up which specific payload is meant in each context.

And: I totally love the introduction of transitory for the transfer-contract!

[miloszm]

Looks Very Good!