Specify hugr-cli extensions

[doug-q]

@ss2165 :

Proposal:

1. Adopt the cargo subcommand model for hugr cli. Move validation and visualisation to builtin sub commands. If hugr-<subcommand> is in PATH hugr subcommand works. Extension subcommands are independent binaries.
2. Publish hugr-runllvm binary from hugr-llvm repo (or perhaps hugr-llvm with optional --run option, without it just outputs LLVM bitcode)
3. Guppy specific compilation passes can be added to hugr build builtin subcommand. Customisable as hugr build --passes "guppy_pre" "guppy_opt_2" "guppy_post", or something similar.
4. Guppy runner python package takes guppy module and strings together subprocess calls to hugr cli as appropriate. (edited)

Questions:

• Does hugr do anything except delegate to subcommands?
• The subcommands must control which extensions are used. This means every "leaf" downstream, which is where extensions are known, needs it's own subcommand.
• Should hugr-cli provide helpers to parse + validate a hugr? What else?

[ss2165]

Maybe the first two questions can answer each other? i.e. hugr main commands only job is attach extensions to hugrs before calling subcommands?

[ss2165]

From @zrho in duplicate issue #1311

Currently the hugr-cli binary can just validate hugrs. To allow for more tooling to be consolidated into the CLI tool, I propose we use subcommands (like cargo and git do). The current functionality can be moved to a validate subcommand, so that it would be run with hugr validate [...]. Clap has good support for this.

[ss2165]

#1312 makes a start on this so closing. Follow up for binary extensibility in #1343 .