wip: upgrade miden VM to 0.17

[lima-limon-inc]

Note: This PR is still in WIP
While working on midenup's tutorial, I tried to create an Account with the miden-client's CLI from the generated .masp that the compiler produced.*

The problem I stumbled upon was that the client failed to deserialize the generated Package from the .masp, erroring out with: unsupported version. Got '[0.0.0]', but only '[1.0.0]' is supported.

If I'm not mistaken, this error originates from a mismatch between the client and the compiler VM's version. The compiler is using version 0.15 of the miden-mast-package crate (which is a crate present in the VM's repo), while the client is using version 0.17 the VM (indirectly via its usage of version 0.11 of the miden-objects crate). Particularly, the Package serialization format got a major version bump from version 0.15.0 to version 0.17.0

So, this PR updates the VM version used by the compiler.

* I added a small experimental-only patch to the miden-client in order to consume the Package.

PR status:

• The compiler compiles correctly (some items are still left as todo!).
• The cargo-miden extension compiles correctly
• cargo miden build manages to compile a basic miden repository generated from cargo miden new without crashing
• The tests are passing

Here's a list of changes that this PR introduces:

• miden-core no longer has the diagnostics feature flag, it got removed.
• miden-core no longer has debug_info, moved to miden-debug-types
• LibraryPathComponent got moved from assembly to assembly-syntax
• miden-lib got upgraded to version 0.11.0 since that's the version that uses miden-vm version 0.17.0
• CompiledLibrary::from_dir got replaced with miden_assembly::Assembler::assemble_library_from_dir(path, ns)
• miden_processor::Digest got replaced with miden_core::Word
• Calls to Assembler::add_module were replaced with calls to Assembler::compile_and_link_moduels.
  • Source: refactor(assembly): improve clarity of Assembler API and its internals miden-vm#1881
• Library::exports now returns a LibraryExport rather than a QualifiedProcedureName
  • QualifiedProcedureName is a field inside LibraryExports
  • recover_wasm_cm_interfaces now returns BTreeMap<masm::QualifiedProcedureName, LibraryExport> instead of BTreeMap<masm::QualifiedProcedureName, MastNodeID>
• PushWord now receives a WordValue instead of miden_core/crypto::Word.
  • Sidenote: These two are functionally equivalent, so maybe turning from one to the other could be added to miden-vm
• MemAdviceProvider no longer exists, and got replaced with AdviceProvider
  • The AdviceProvider struct is now a struct instead of a trait.
    • Convert AdviceProvider into a struct miden-vm#1904
    • chore: refactor AdviceProvider into a struct (#1904) miden-vm#1906
  • The From<AdviceInputs> implementation appears to have changed:
    • https://github.com/0xMiden/miden-vm/pull/1906/files#diff-85878d724f2a08e6699a6aee82671ae03ea3875b534542742ec24f65d482892bR275-R284.
    • https://github.com/0xMiden/miden-vm/pull/1906/files#diff-8923b3cb260883d388184f2981d27d35231bc3d82d4fc4d4f37c8eb67305fb43L233-L238
    • Question: Is this change intended?
• The Host trait got moved into BaseHost.
  • In host.rs, DebuggerHost implements both BaseHost and SyncHost. Some function implementations are still left as todo!()'s
  • Question: Should AsyncHost be implemented as well?
• PackageExport now incluldes funciton signature (updated in assemble.rs).
• SourceFile no longer has a path() method, now it's construted from like so: Path::new(source_file.uri()). Seen in breakpoint.rs. Question: Should uri.as_path() be used?
• QUESTION: Should ResolvedLocation receive a LineNumber and ColumnNumber instead of two u32?
• Update miden-objects to version 0.11.0
• The VM's default MAX_CYCLES changed from u32::max to 536870912 (1 << 29 )
• The code produced in the array.masm test changed with the following diff: (this also happened to multiple other tests)

  -     push.2552035692683956824
  -     push.5323511717551755022
  -     push.6168074652703322390 
  -     push.2298154438505521656 
  +     push.[2552035692683956824,5323511717551755022,6168074652703322390,2298154438505521656]
  

  • I updated the test's expected output to the new output. Question, are these two equivalent?
• Assembler::add_library got renamed to Assembler::link_dynamic_library

Sidenote for reference: The diff before the Cargo.lock files were included was +249 −241.

[lima-limon-inc]

Sidenote: This change is not realted to the VM update itself, the integration tests pass with the previous version as well.
However, shouldn't MastArtifact's serialization function be called, instead of calling the underlying variant's serialization function. There is a slight difference in serialization, mainly the presence of the initial MagicBytes when serialized via MastArtifact.

Here's MastArtifact's serialization when there's an underlying Library:
https://github.com/0xMiden/miden-vm/blob/da78ba2ab0db3e092d063e5526c0cd3ddee7163a/package/src/package/serialization.rs#L158-L161

And here's the Library's:
https://github.com/0xMiden/miden-vm/blob/da78ba2ab0db3e092d063e5526c0cd3ddee7163a/assembly-syntax/src/library/mod.rs#L409-L428

[lima-limon-inc]

If I'm not mistaken, WordValue and Word are two equivalent structs.
Here's WordValue's definition: link
And here's Word's: link, with WORD_SIZE_FELT being 4: link

Additionally, I believe before this PR (0xMiden/miden-vm@de03313), Word was used directly.

[lima-limon-inc]

This commit 0xMiden/miden-vm@62275e9 in version 0.17.1 introduced the LineNumber and ColumnNumber structs.
Should these be used here as well?

[lima-limon-inc]

I removed this bit since it was also removed in this previous PR: https://github.com/0xMiden/compiler/pull/593/files#diff-4e5cd1ed11ee24544998276064a9b2726f61bf08a7fc9c1490b8f87e45d9125bL53-L61