Inconsistent OpTrait::other_{input,output} and OpType::static_{i,o}_port behaviour.

[aborgna-q]

The Const operation defines its OpTrait::other_output as the EdgeKind::Static port with the const data.

hugr/src/ops/constant.rs

Lines 108 to 110 in 968c8b0

	fn other_output(&self) -> Option<EdgeKind> {
	Some(EdgeKind::Static(self.typ.clone()))
	}

This port is then exposed by OpType::other_output_port.

On the other hand, OpType::static_output_port uses different logic to define the static output for Const;

hugr/src/ops.rs

Lines 196 to 201 in 968c8b0

	/// If the op has a static output (Const, FuncDefn, FuncDecl), the port of that output.
	pub fn static_output_port(&self) -> Option<OutgoingPort> {
	OpTag::StaticOutput
	.is_superset(self.tag())
	.then_some(0.into())
	}

This same situation happens with FuncDecl and FuncDef.

static_output_port is rarely used, so we haven't seen problems yet, but it makes the logic inconsistent.

---

If we compare the corresponding methods on the incoming side; we have Call and LoadConstant with hard-coded static inputs:

hugr/src/ops.rs

Lines 188 to 194 in 968c8b0

	pub fn static_input_port(&self) -> Option<IncomingPort> {
	match self {
	OpType::Call(call) => Some(call.called_function_port()),
	OpType::LoadConstant(l) => Some(l.constant_port()),
	_ => None,
	}
	}

Both use DataflowOpTrait's default other_port; a StateOrder.

hugr/src/ops/dataflow.rs

Lines 20 to 22 in 968c8b0

	fn other_input(&self) -> Option<EdgeKind> {
	Some(EdgeKind::StateOrder)
	}

static_input_port has multiple references in the code, where it gets used as a separate thing from other_input_port.

---

One would expect the same behaviour between input and output, so I consider this inconsistency a bug.
I'd propose changing the output_ports to mimic the input behaviour.