Add high-level types in Miden SDK on a case-by-case basis

[greenhat]

Following up on the #436 (comment)

The original idea was to have two sets of types.

Low-level type in miden-base-sys crate:

struct CoreAsset {
  inner: Word
}

And a high-level in miden-base crate:

enum Asset {
  Fungible(FungibleAsset)
  NonFungible(NonFungibleAsset)
}

struct FungibleAsset {
    faucet_id: AccountId,
    amount: u64,
}

struct NonFungibleAsset(Word);

For every type that we want to use in the component API, we need to define it in the WIT format, which limits us to the WIT type system. Although we are remapping the WIT types to our custom Rust type, it should have the same shape as the WIT type since the lifting/lowering of the types are not customizable (yet).

This makes me wonder if we would be better off with just the low-level types and exposing all the functionality of high-level types via the low-level type's methods. We can still define additional "helper" types in Rust land without mentioning them in WIT, as long as they are not used in the component API.

Pros:

1. No need to convert to/from low-level types (Word) when calling MASM code (stdlib, tx kernel);
2. Cheaper passing through the component API due to simpler lifting/lowering;
3. Only one set of types;

Cons:

1. Some overhead when accessing the fields in the inner Word;
2. Field access only via getters/setters;

If we choose to go with only the low-level types, then we need to rename CoreAsset to Asset.

[bitwalker]

My understanding is that the high-level types were intended for use within the user's code, not on component boundaries, i.e. you'd do something like Asset::from(core_asset) (inbound) and assert.into() (outbound), and then be able to work with the high-level representation everywhere that matters in your own code. To me that still seems valuable.

I generally agree that trying to use the high-level types on component boundaries is probably not worth it, but it is one of those things that can be taken on a case-by-case basis, depending on the layout of the type in question. For example, enums-with-data, like Asset, when decorated with #[repr(C)], have a well-defined layout that might be compatible with a more verbose WIT equivalent (e.g. as a pair of u32 + u64, where one holds the discriminant, the other holds the data). That said, we don't have to try and make that sort of thing work, I think the important thing is allowing user code to be as ergonomic as possible without imposing a lot of ceremony (which is why it would be nice to use the high-level types at boundaries too, but may not be worth the downsides in all cases).

I think for now, the low-level types obviously take precedence, since they form the foundation, but I think we'll want to continue to try and make use of high-level types as much as possible - both to come up with strategies that users of this tooling can follow in their own APIs, as well as to better feel out the pros and cons. Ultimately, if the compiler has to hold a bunch of complexity to deal with this, but we can allow users to not even be aware of the distinction, then I'd rather take on that burden than push it on them.