Miden SDK proof-of-concept using Wasm component model

[greenhat]

Close #72

This PR adds a WIT implementation of Miden SDK and a basic wallet test using the Wasm component model.

Design decisions

Marking call-able functions (account type)

I chose to mark the whole Wasm component as having call-able functions. The benefits vs. marking individual functions as call-able are:

• Data segments contain the data for all functions in the component, so we have lower chances of loading unwanted data;
• Marking the individual functions can be done only via an attribute in the doc string, which is more error-prone than marking the whole component. Plus, I'm pretty sure we'll want to treat the account code specially, so we'll have to mark the whole component anyway.
• The whole component is marked via exporting a "marker" interface (see account interface defined in miden.wit(SDK) and used in basic-wallet.wit). Alternatively, we can use metadata in the Cargo.toml where will define some properties of the Miden component anyway.

Wasm components are limited to one exported world, so we cannot have both call-able and exec-able functions in the same component with this approach. That is the drawback of this approach.
The helper function are expected to be linked as a regular Rust crate to avoid the CanonicalABI overhead when called.

Wasm resource does not play well with call, so we should not use it

I found a problem that I believe prevents us from using the resource for our types. As an experiment, I made Asset a resource and since the implementation is opaque (see) and not on the WIT "level" (see) there is no knowledge of the size of the Asset instance in the compiled Wasm component. The resource handle is a pointer to the instance. Thus making it impossible to pass the resource value via a call.
As I understood from the generated code, the resource is passed as a pointer to the instance, and since its methods are implemented in the Wasm component where the resource instance "resides," they can access its memory directly no matter from what component they were called.

Use "library" Wasm component for note instead of a "command"

When using "command" Wasm component the runtime is quite sizable and pulls in arg parsing and thread-related setup that we don't need. So I decided to use a "library" Wasm component instead that is implementing a note interface (see).

[greenhat]

@bitwalker Following our discussion, I removed the component with the account's helper functions.

[bitwalker]

A couple small notes, but I think this looks good so far!

We discussed the following on our compiler call today, but just to document the decisions somewhere relevant:

1.) The need to avoid resource at the moment is due to missing features in the VM, for which we have an outstanding proposal that may or may not enable the use of resource in the future - but for the time being it can't be used.

2.) As you noted, all public exports of a component should be called, and we formalized that decision today (though it isn't final if we decide to revisit that in the future for some reason).

[bitwalker]

LGTM!