Move standards types from `miden-protocol` to `miden-standards`

[PhilippGackstatter]

As a follow-up to #2197, I think we should move some types from miden-protocol to miden-standards. The main motivation is to have types that are likely going to be extended in the future in the standards crate rather than in the protocol crate. Additionally, the protocol crate is fairly large after #1563 and this makes it a bit leaner.

This applies to:

• miden_protocol::asset::TokenSymbol
  • used as part of fungible faucet metadata, which are defined as miden standards.
• miden_protocol::address
  • The Address is not something that is inherently a part of the protocol, but more like a tool for working with it. The AddressInterface and RoutingParameters are meant to be extended through standardization and so it makes sense to have it in the standards crate.
  • Something to figure out here is how to make AddressId::decode delegate to AccountId::from_bech32_byte_iter without making types from the bech32 crate part of our public API. This can probably be done fairly simply by changing the iterator parameter to an impl Iterator<Item = u8>.
• miden_protocol::account::component::AccountComponentMetadata
  • This could be moved optionally. There could be multiple account component metadata formats and this is just one of them, so making it a standard makes conceptual sense, though quite likely, there won't be another one. So, the main benefit would be to make the protocol crate leaner.
    • Requires moving AccountComponent::from_package to standards crate.
• miden_protocol::account::auth::{AuthScheme, AuthSecretKey, PublicKey, Signature}.
  • These are less clear to me. They are used protocol-wide, and so one could argue that defining them in the protocol crate is fine. They are likely to be extended in the future with more standardized auth schemes, so it could make sense to move these to standards, or at least there should be no downside to doing so.
    • This requires moving AccountFile to standards as well, but that seems fine. If we do that, it probably also makes sense to move NoteFile.
    • One issue is that TransactionArgs::add_signature relies on Signature, and so moving these types would require a different solution here, like a trait or moving add_signature (as an extension trait) itself to standards. I think the latter makes the most sense.
    • Even if we move this to standards, it should be fine to keep miden_protocol::crypto re-exports.

I think TokenSymbol and Address make sense to be moved. For the other two I'm less convinced, but would lean towards moving them.

If we decide to move these, each of these high-level bullet points should be done as a separate PR.

[CreeptoGengar]

Hmm, I think I might be able to do it

[bobbinth]

I'd probably move the Address struct first as it should be the easiest to move.

After that, we could move TokenSymbol - but I'd wait until we complete the work on AccountComponent refactoring. This may include #2210.

The others, I'd keep in miden-protocol for now, and we can re-visit them later.

[PhilippGackstatter]

@CreeptoGengar Thank you! I've assigned you the issue. Could you work on moving the Address from miden-protocol to miden-standards? We should be able to move the entire address module to crates/miden-standards/src/address/. See also the point in the issue above regarding the change to impl Iterator<Item = u8>.