Implement `AccountComponent`s

[PhilippGackstatter]

Description

This PR implements AccountComponents. An AccountComponent defines a Library of code and the initial value and types of the StorageSlots it accesses.

One or more components can be used to built AccountCode and AccountStorage.

Each component is independent of other components and can only access its own storage slots. Each component defines its own storage layout starting at index 0 up to the length of the storage slots vector.

Components define the AccountTypes they support, meaning whether the component can be used to instantiate an account of that type. For example, a component implementing a fungible faucet would only specify support for AccountType::FungibleFaucet. Using it to instantiate a regular account would fail. By default, the set of supported types is empty, so each component is forced to explicitly define what it supports.

The PR implements three pre-defined components:

• BasicWallet,
• RpoFalcon512,
• BasicFungibleFaucet.

These can be combined to build an account from components. Typical usage would look like this:

let (account_code, account_storage) = Account::initialize_from_components(
    AccountType::RegularAccountUpdatableCode,
    &[RpoFalcon512::new(pub_key).into(), BasicWallet.into()],
)?;

let account_seed = AccountId::get_account_seed(
    init_seed,
    account_type,
    account_storage_mode,
    account_code.commitment(),
    account_storage.commitment(),
)?;

let account = Account::new(account_seed, account_code, account_storage)?;

Other Noteworthy Changes

• Remove if statement in validate_procedure_metadata and consistently implement the rule that procedures that do not access storage have offset and size set to 0 (for faucets this was (1, 1) previously).
• Remove AccountCode::{compile, new} as it should typically be instantiated using Account::initialize_from_components or AccountCode::from_components as a fallback.
• Renames "default account code" to basic authenticated wallet, as that seems more descriptive.
• Most mocked AccountCode was replaced with components, often AccountMockComponent.
• Technically it would be correct to implement the num procedures == 0 or > 256 check in AccountComponent::new, but it seems convenient to not do this and only do it in AccountCode::from_components for two reasons:
  • We might want to have a component with an empty library but some storage slots in testing code to force a certain storage offset and size combination.
  • There is no need to unwrap/expect when impl From<MyComponent> for AccountComponent since AccountComponent::new is infallible.

closes #935

[PhilippGackstatter]

@bobbinth I addressed all your comments now and am creating new issues for the leftover tasks.