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?