feat: implement multi-command aliases

[Keinberger]

Summary

This PR moves aliases to channel-level pipelines so a single alias can orchestrate multiple components. This was discussed in #129 . Each step now names both the component and the command tokens, and user arguments are appended only to the first step. miden resolves and executes every step in order, enabling cross-component flows (for example, miden-faucet followed by miden-client, i.e. mint command).

Partial toolchains retain only those aliases which steps target installed components. The manifest (manifest/channel-manifest.json) has been updated to the new channel-level alias shape.

Details

Channel-level aliases (breaking change)

Aliases are no longer stored under individual components. Each channel now has a top-level aliases map (HashMap<Alias, Vec<AliasStep>>). Each AliasStep must specify a component (the component whose executable should run for this step) and a command (the existing CliCommand tokens: executable, lib_path, var_path, or verbatim strings). For example:

"aliases": {
  "mint": [
    { "component": "faucet", "command": ["executable", "mint"] },
    { "component": "client", "command": ["executable", "sync"] },
    { "component": "client", "command": ["executable", "consume-notes"] }
  ]
}

Resolution prefers the active channel’s aliases and components and falls back to the installed channel with warnings. Partial installs keep aliases only if all steps target installed components.

Multi-step execution

miden now resolves and runs each alias step sequentially. User CLI arguments are appended only to the first step, and a --help request is appended to the first step’s arguments. A helper resolves each step to (program, args) using the step’s component.

Note on data passing

Data passing between steps (capture and templating) is not part of this PR, but required as a subsequent PR for implementing issue #131 to finally implement the mint command.

Closes #129

[igamigo]

How does this implementation relate to the one of #130?

[Keinberger]

How does this implementation relate to the one of #130?

Oh, just saw that @lima-limon-inc was working on implementing this in parallel to me. Makes me think that we need better coordination on changes that come to midenup.

I like the implementation on #130 more, as it requires way less code changes compared to this PR. Because of that, I will convert this PR to a draft, and close it once #130 is merged.

On the other hand, I'd like to mention that the reason for the bigger number of code changes on this PR is due to the fact, that I moved the aliases outside of the individual components struct. The reason for that is, because the future mint command will execute commands form both the miden-faucet and miden-client. Keeping the aliases inside of the individual executables would make that less ideal.

Fabrizio also pointed that out in his PR description, see here:

CliCommand::Executable now requires the following argument to be of type CliCommand::Verbatim with the name of the component that needs to be executed.
This does mean that component specific aliases now require to redundantly add their own name in the aliases, like so.
Additionally, it does mean that a component could technically use a different component's binary in its alias. While not ideal.