Introduce `AssetComposition` enum

[PhilippGackstatter]

See the parent issue for higher-level context.

Instead of encoding how assets compose at the account level, we can encode it at the asset key level, decoupling accounts from assets.

This structure could look like this:

/// Its [`Word`] layout is:
/// ```text
/// [
///   asset_id_suffix (64 bits),
///   asset_id_prefix (64 bits),
///   [faucet_id_suffix (56 bits) | reserved (5 bits) | asset_compose (2 bits) | callbacks_flag (1 bit)],
///   faucet_id_prefix (64 bits)
/// ]
/// ```
/// 
/// `asset_structure` is unused for now.
pub struct AssetVaultKey {
    faucet_id: AccountId,
    asset_id: AssetId,
    composition: AssetComposition,
    callback_flag: AssetCallbackFlag,
}

// Describes how fungible assets are composed - merged, splitted and compared.
pub enum AssetComposition {
    // Used for assets that cannot be composed, e.g. non-fungible assets.
    None,

    // Tx kernel composes assets by using fungible_asset::{merge, split}, i.e. a basic way to
    // compose fungible assets.
    Fungible,

    // Tx kernel calls out to the faucet for composing assets.
    // Enabled in the future.
    Custom,
}

This requires an update to how the type of an asset is extracted, deep in crates/miden-protocol/asm/shared_utils/util/asset.masm

Once we change how an asset type is identified, two places need an update:

• asset_vault::{add_asset, remove_asset} must handle assets uniformly and base the compose logic on the AssetComposition instead of the account ID type. This would be the time to implement generic asset addition and removal logic instead of branching on the type.
• Account delta needs to be updated, which is the topic of a separate issue and may be good to do before this issue.