[1/x] Miden SDK as plain Rust dependencies

[greenhat]

Ref #138
Ref #118

This PR adds:

• miden-sdk crate with a small subset of tx kernel API functions, one for each transformation strategy, with partial transformation of the parameters and results on the Rust side (bindings);
• infra in the frontend-wasm crate to recognize and transform parameters and results for function calls for these well-known functions during the Wasm translation;

The native Felt type is not implemented in this PR and will be added in the next PR.

[greenhat]

@bitwalker I got to the point where I need to figure out where to put the Wasm module import (Miden SDK extern function) in the IR.

How to represent a Miden SDK extern function Wasm import in IR?

Component-level import vs. module-level import.

As a component-level import

Pros (vs. module-level import):

• Concentrating lowering/lifting logic in one place; One can view the generation of the adapter function from C ABI to the kernel tx ad-hoc ABI as a lowering/lifting of sorts.
• When we switch to WIT-based Miden SDK in the future, the lowering/lifting logic's place will remain unchanged, only the logic itself will change.

Cons (vs. module-level import):

• Introduces a different kind of component import in the IR that will require special handling;
• Wasm component import is called, while Miden SDK import is execed; Although one could argue that it's a lowering/lifting implementation detail.
• Requires generating a synthetic component to wrap the Wasm module since the Rust compilation produces only a Wasm module; Although, we might need to do this anyway for tables (see comment) so this point might actually be moved to pros.

I want to go with component-level import, and I'm starting to draft the code for it. What do you think?

[bitwalker]

@greenhat Now that I've finished rebasing/merging the other PRs, since you are still working on this one, you'll need to create a new temporary branch off of main, then cherry-pick your commits made for this PR to that new branch (not the other commits that GitHub thinks are now part of this PR, so a simple git rebase main isn't an option here), then force push, i.e.

1. git checkout main && git pull origin main && git checkout -b temp
2. Cherry-pick c564e5b and everything after it to temp
3. While still in temp branch: git branch -D greenhat/i138-rust-miden-sdk && git checkout -b greenhat/i138-rust-miden-sdk && git push --force origin greenhat/i138-rust-miden-sdk && git branch -D temp.

You probably already know the process, but just to make sure everything is painless as possible, that's what I would do. There will be conflicts due to the formatter changes, but most things should be straightforward.

As mentioned in one of my review comments on the other PRs: the Tuple type was discarded in favor of Struct types, since there is no semantic difference between them, so if you run into any conflicts due to that, just replace any uses of Tuple with Struct and you should be good to go.

Happy to answer any questions about any of the new changes as well, just let me know.

[greenhat]

Sure, will do. Thanks for the detailed steps and thanks for taking care of my previous PRs.

[greenhat]

@bitwalker Thank you for the detailed review notes! I addressed them all. Please, make another round.

[bitwalker]

Just as a heads up, we should make sure that any function type which would be handled as no_transform, uses Abi::Canonical so that it goes through the normal lowering process. For the other Abi variants, we either want to transform them such that they are Canonical, or that they require no further transformation aside from direct translation to Miden Assembly.

To be clear, haven't checked to see if that's already the case anyway, but wanted to raise it just in case that conflicts with what your operating assumptions are.

[greenhat]

Good point! Actually, since all the Miden ABI transformation happens in the frontend, I'll use Abi::Canonical for all the function type definitions because all of them should have this ABI after the processing regardless whether an actual transformation was conducted. This means that Abi::Miden is not used, so it can be deleted. Keep in mind that Abi is not included in Signature. Besides that, I removed (abi XXXXX) in ComponentImport textual form and printed it as part of FunctionType in the textual form.
All the aforementioned changes are made in the #156 due to their invasive nature to the two subsequent PRs that makes rebasing a PITA. See commit 82870e3

[bitwalker]

Looks good! Just a couple last questions/notes, but I'll sign off and let you respond/handle those as you see fit.

I'll try to get to your next PR tomorrow, Friday at the latest!

[bitwalker]

LGTM!