refactor: use CodeBuilder

[igamigo]

I think #187 got closed when the base branch got merged.

Official guidance should be to utilize the CodeBuilder, which is also provided by Client. Recently mixing source managers in assemblers started resulting in internal panics (0xMiden/miden-vm#2778), so we need to make guidance as consistent as possible. This also simplifies code a bunch. cc @Keinberger @BrianSeong99

Closes #188.

[bitwalker]

Just a quick aside - but I'd recommend switching over to using projects (i.e. defined by a miden-project.toml file) and the project assembler in our tutorials, rather than manually assembling things. Not only is the API surface way simpler that way, but you automatically get a Miden package as output.

I'm hoping to expand miden build by the next release so that it can assemble both Rust and MASM projects directly, so it should basically never be necessary to construct an Assembler directly as an end user to get a package.

[Keinberger]

+1 on landing this as the official guidance. I did a very similar migration on #192 last week while fixing tutorial issues from #191 and converged on the same shape, so independent confirmation it's the right move.

@bitwalker I'm bought on project-assembler as the destination, just not for tutorials in this iteration. Couldn't find any miden-project.toml with kind = "account-component" in the workspace, the schema doesn't seem to cover storage slots / supported account types, and inline MASM isn't supported (Target.path is file-only), which would fragment the doctest snippets in docs/. Without the miden build CLI wrapper for MASM, the reader's first contact is Assembler::for_project_at_path(..., &mut InMemoryPackageRegistry) from Rust, which is heavier than client.code_builder() for "deploy your first counter".

Happy to take a fresh PR at it once miden build covers MASM and there's an account-component example to copy from.

Should we open an issue for this?

[bitwalker]

@Keinberger That's fine as a temporary step, the next compiler release already supports compilation of both Rust and MASM projects (and mixed projects), so at that point, miden build will "just work".

I do want to give you a heads up that I'm aiming for a state, ASAP, where the miden-assembly crate is not directly depended upon by downstream components like miden-client. Doing so makes the client (or node, etc.) extremely brittle, in that we cannot ship any MASM fixes/improvements without a full release cycle, which introduces an enormous delay in the feedback loop (I've been fighting this for a year+). So I'm shooting for us to have all the pieces in place so that tools like the client assemble via the CLI tooling (e.g. miden build, or midenc directly), rather than embedding the assembler crate. This allows shipping the assembler independently of the VM/protocol/node, so long as no changes to MAST or the package format are required (in which case such changes would require a much more involved migration process and full release cycle).

I want to give you that heads up so that the process of shifting things that direction can start sooner rather than later, but until the 0.23.x VM release has shipped all the way to devnet/testnet, we're not quite there yet (though I think that's supposed to happen this week/next).

Couldn't find any miden-project.toml with kind = "account-component" in the workspace, the schema doesn't seem to cover storage slots / supported account types

The compiler has various examples of this (or at least the branch which adds project support does, but that should be merged later tonight). That said, I was anticipating that project stuff would be documented as part of the main Miden docs (and here in the form of tutorials) - but if there are specific documentation aspects missing in the miden-project crate (and I can think of a couple), just ping me with a list.

inline MASM isn't supported (Target.path is file-only)

That's incorrect - the path can be elided (such targets are called virtual targets), in which case you need to use project_assembler.assemble_with_sources and provide the source inputs yourself. I do have some improvements in mind here, but in general I don't want end users consuming the miden-assembly crate APIs directly anyway, for the reasons I outlined above.

..the reader's first contact is Assembler::for_project_at_path(..., &mut InMemoryPackageRegistry) from Rust, which is heavier than client.code_builder() for "deploy your first counter".

Sure, that's fine. Ultimately we want people using miden build anyway, not using the assembler in Rust, so until that path is cleared, keeping things simple up front makes sense.