chore: refactor tx kernel from ASSET to ASSET_KEY and ASSET_VALUE

[PhilippGackstatter]

This PR refactors the tx kernel internals from the previous ASSET to ASSET_KEY and ASSET_VALUE. I.e. assets are now represented by two instead of one word.

To keep this change managable:

• The asset key is temporarily derived from the asset value at the kernel procedure API boundary (api.masm). In one of the next PRs, this will go away and the kernel procedures will instead take the key in addition to the value.
  • Importantly, the asset value is unchanged: It still has the same layout as before. So, in isolation, this change is weird because the key can always be derived from the value, but this is a temporary thing and in a subsequent PR, the faucet ID will be removed from the asset value.
• Most changes are only in the tx kernel, but it wasn't possible to keep them entirely contained there. The one change that bleeds through in this PR is that the assets commitment is computed over key and value instead of just the value. This affects the get_assets kernel procedure.

Notable changes

• Computing assets commitment is now both conceptually easier and also easier in the implementation. It uses the various double-word hash procedures from miden::core.
  • Simplify NoteAssets by implementing SequentialCommit.
• output_note::add_asset was refactored heavily. It now uses a single procedure for both fungible and non-fungible assets which should prepare nicely for the unified assets in the short-term future.
  • add_asset_raw logic can later be generalized to: if asset is found and can be merged (merge procedure is not EMPTY_WORD) it will call it, otherwise it will abort.
• Semantically, asset origin checks (for faucet mint and burn) or whether an asset is fungible or non-fungible is now checked against the vault key instead of the asset value.
• asset_vault::remove_asset takes the ASSET_KEY and ASSET_VALUE to remove from the vault. The reason the value is required is so an asset can be partially removed from the vault, e.g. "remove 30 tokens from the total of 80 tokens in the vault". This can work similarly in the future with assets that are splittable (e.g. fungible assets).
• faucet::burn currently returns the same ASSET_VALUE that it takes as input. It should either be removed (in line with add_asset_to_note procedure results overhead when calling from Rust #1717) , or return the previous value of the vault. I think the latter makes the most sense as it makes the API strictly more useful. For that reason, I kept the return value so we can more easily change this in the future. The same applies to native_account::remove_asset.
  • see Avoid returning outputs identical to inputs in kernel procedures #2523
• Fix procedure signature of mint_fungible_asset. It previously suggested it returned the same asset it took, but it actually returns the merged asset.

Review

The most heavily refactored modules are asset, asset_vault, output_note.

Note that asset.masm will change again when changing layouts of asset keys and values, so a very deep review may not be necessary at this point.

I tried to keep the commits organized by the module that was refactored (and what conceptually was updated as a consequence), so reviewing by commit should be mostly fine.

Migration

Calls to {input_note, active_note, output_note}::get_assets must be updated since the returned memory layout has changed from previous [ASSET] to [ASSET_KEY, ASSET_VALUE].

Potential Follow-Ups

• NoteAssets::add_asset recomputes the commitment every time. Tracked in Consider removing NoteAssets::add_asset #2525.
• faucet::burn should return previous value. E.g. if we have a total of 80 tokens in the vault and 30 are burnt, then 50 should be returned. This may be useful, for example, to easily check what the remaining balance is after burning. For instance, faucets::burn could set token_supply to that returned value after the burning. The same applies to native_account::remove_asset. see Avoid returning outputs identical to inputs in kernel procedures #2523

part of #2328

[mmagician]

review WIP :)

[mmagician]

LVGTM!

[mmagician]

@copilot work on the nits from @mmagician 's PR review

[Copilot]

@mmagician I've opened a new pull request, #2438, to work on those changes. Once the pull request is ready, I'll request review from you.

[bobbinth]

Looks good! Thank you! I left some comments inline, but pretty much everything could be addressed in follow-up PRs.

[huitseeker]

This validates key and value separately, but doesn’t check they match. If a caller can pass mismatched key/value, origin checks will use the key and ignore the faucet ID in the value.

Should we assert build_asset_vault_key(ASSET_VALUE) == ASSET_KEY here (or in validate_*) and/or add a test?