feat: Replace Circuit::num_gates with num_operations

[aborgna-q]

Closes #105. Closes #108.

num_gates used to count every node in the top-level region, giving unexpected results on results with constants, control flow, or anything other than simple gates.

num_operations now only counts CustomOps, traversing containers as needed.

I also improved the circuit unit tests, to include circuits in modules and circuits in FuncDefns (instead of DFGs).

Some notes:

• Part of the tests testing parametric operations is commented out until we solve Can't define a circuit with constant parameters hugr#1166.
• Although the test circuits have function names, Circuit::name returns None. I'll address that in another PR.

[codecov]

Codecov Report

Attention: Patch coverage is 73.68421% with 10 lines in your changes missing coverage. Please review.

Project coverage is 82.76%. Comparing base (50ee0fa) to head (9b17a6e).
Report is 1 commits behind head on main.

Files	Patch %	Lines
tket2/src/circuit.rs	67.85%	1 Missing and 8 partials ⚠️
tket2/src/rewrite/strategy.rs	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #384      +/-   ##
==========================================
- Coverage   83.32%   82.76%   -0.56%     
==========================================
  Files          48       48              
  Lines        5042     5042              
  Branches     4591     4591              
==========================================
- Hits         4201     4173      -28     
- Misses        654      674      +20     
- Partials      187      195       +8     

Flag	Coverage Δ
python	97.33% <ø> (ø)
rust	81.33% <73.68%> (-0.61%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ss2165]

docstring is innacurate (X not Rz)

[ss2165]

we don't have some existing graph/hierarchy traversal we could use? is this to avoid petgraph dependencies?

[aborgna-q]

There's hugr::DescendantsGraph but that's optimised for arbitrary accesses to the HugrView.
It keeps a cache of nodes it knows are in graph in a RefCell<HashMap<_,_>>, and updates it as it filters throught.
We can skip that here since we have a set traversal order.

I guess we could optimise that in Portgraph. I'll open an issue, but leave the explicit loop here for now.

[ss2165]

why not just iterate over all nodes in the hugr?

[aborgna-q]

Because we only care about the region describing the circuit, and its descendants.

If the hugr defines a module with multiple functions, we should only traverse the circuit's. E.g.

tket2/tket2/src/circuit/command.rs

Lines 528 to 538 in 9b17a6e

	/// 2-qubit circuit with a Hadamard, a CNOT, and a T gate,
	/// defined inside a module containing other circuits.
	#[fixture]
	fn module_with_circuits() -> Circuit {
	let mut module = simple_module();
	let other_circ = simple_circuit();
	let hugr = module.hugr_mut();
	hugr.insert_hugr(hugr.root(), other_circ.into_hugr());
	return module;
	}

This gets a bit interesting with any kind of control flow; should function calls count towards the operation count? Should conditionals count each branch?

Here I went with the best-defined option: traverse embedded DFG blocks, but ignore any control flow primitives.

[aborgna-q]

Leaving this here to register the backlink:
CQCL/portgraph#135