feat: Support LineConvexChecker

[lmondada]

This PR's goal is to expose the new LineConvexChecker in portgraph in the hugr API. For details see the original PR: CQCL/portgraph#240

This PR will require a (non-breaking) portgraph release. Currently pinning portgraph main (to be reverted).

There are also two functions whose API could be generalised -- but that would be a breaking change. I've marked them as TODOs in the code.

Breaking change?

Confirm: hiking the patch version of portgraph is considered non-breaking, right?

The current "breaking change" detected by semver-checks is due to struct TopoConvexChecker now being a type synonym for ConvexChecker<'g, Base, pg:TopoConvexChecker<CheckerRegion<'g, Base>>>. It behaves exactly identically from a user's perspective, so I would be in favour of ignoring that warning, unless someone can spot an issue with it?

Alternatively, I could define a newtype struct TopoConvexChecker(ConvexChecker) that delegates all methods to the inner struct. Presumably semver-checks would accept that as non-breaking (but it would be ugly, verbose and would need to be undone before the next breaking release).

[codecov]

Codecov Report

❌ Patch coverage is 77.02703% with 34 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.66%. Comparing base (c3370fe) to head (8076a45).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
hugr-core/src/hugr/views/sibling_subgraph.rs	77.02%	34 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2487      +/-   ##
==========================================
- Coverage   82.67%   82.66%   -0.01%     
==========================================
  Files         251      251              
  Lines       46661    46786     +125     
  Branches    42190    42315     +125     
==========================================
+ Hits        38576    38675      +99     
- Misses       6034     6060      +26     
  Partials     2051     2051              

Flag	Coverage Δ
python	91.38% <ø> (ø)
rust	81.74% <77.02%> (-0.01%)	⬇️

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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hugrbot]

This PR contains breaking changes to the public Rust API.
Please deprecate the old API instead (if possible), or mark the PR with a ! to indicate a breaking change.

cargo-semver-checks summary

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
      ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
     impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.42.0/src/lints/struct_missing.ron

Failed in:
struct hugr_core::hugr::views::sibling_subgraph::TopoConvexChecker, previously in file /home/runner/work/hugr/hugr/BASELINE_BRANCH/hugr-core/src/hugr/views/sibling_subgraph.rs:601

[lmondada]

@aborgna-q my thoughts

• I cannot think of a scenario for which swapping an opaque struct with a type alias would break code
• even if there is an edge case that we are not thinking of right now, I highly doubt someone will stumble on it given that (afaik) the only user of this is tket

So rather than whether this is breaking, for me the question is whether it's worth the hassle to overwrite semver-checks (because I think it creates issues when generating the changelog, right?)

Whilst we're at it, can you confirm that hiking the portgraph dependency wouldn't be breaking? It would be a patch upgrade on portgraph.

[lmondada]

An alternative is to play it safe (i.e. define TopoConvexChecker not as a type alias but a newtype wrapping ConvexChecker), and then already create the breaking PR that will undo this (as well as generalising the fn signatures currently marked as TODO). Then we'd leave the breaking PR hanging around until the next breaking release?

There shouldn't be too many merge conflicts arising, given that it only touches this one file.

[aborgna-q]

Relevant semver-checks issue: obi1kenobi/cargo-semver-checks#609 (comment).

I think we're fine overwriting the breaking change marker here.
We should do the overriden patch release soon after merging this to avoid headaches later.

[lmondada]

(nit)

Relevant semver-checks issue: obi1kenobi/cargo-semver-checks#609 (comment).

Our case is slightly different: the type alias and struct are both defined within this crate, so the justification does not apply. However, in our case, the aliased struct isn't equal to the old one (it is equal once some of the generics are fixed).

Do you think I should open an issue in semver-checks?

[aborgna-q]

Uhm, you're right though it's quite the edge case.
May be worth reporting it if you have some free at some point.