Wrap an OpType to take/produce linear token types

[acl-cqc]

When we remove Order edges (yes!), this could be helpful. (Is it important? That may be part of the discussion.)

For container ops, also Input/Output, it's fairly easy, just add to the list of types (and wire from Input to Output).

For other ops, there are a few possibilities:

1. Metadata. Wrap the Op in a DFG, and define a metadata tag that means "do not inline" (e.g. disable InlineDFG). The tag also ensures that hugr-llvm generates code that executes the body only after all dfg inputs are "available" and before making any dfg outputs available.
2. Add an extra OpType::PassthroughWrapper(Type, OpType). That'd compute its port requirements by consulting the inner OpType (perhaps another PassthroughWrapper, so no need to make Type into Vec<Type> - that would only reduce normalization), and add one port. (At the end, so as not to confuse any port-number-computation logic in the inner OpType - potentially the big problem here.)
3. Keep the existing OpType enum which can be pattern-matched (but does not know about the extra ports), add a struct wrapping an enum OpType with a Vec of extra ports (supporting all existing OpType functions - e.g. port counts by delegating to the inner enum and adding the Vec - and as_foo methods returning the enum only). Note there'd be no single entity that both supported pattern matching and knew about the extra ports, although we can support as_xxx alongside extra ports (without pattern matching); you could have into_inner() returning the enum (matchable, without extra port knowledge), add another method alongside HugrView::get_optype, etc. - all quite disruptive. (There may also be tie-in with Unify Term with Value, and add function pointers #2705.)
4. Add extra port information separately into every Optype variant. This might provide the least disruptive migration for clients, but a lot of duplication at the Hugr end.