feat: Add crate::algorithm::iter

[doug-q]

No description provided.

[codecov]

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

Comparison is base (3314404) 84.12% compared to head (4772158) 84.18%.
Report is 1 commits behind head on main.

Files	Patch %	Lines
src/algorithm/iter.rs	91.42%	3 Missing and 6 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #830      +/-   ##
==========================================
+ Coverage   84.12%   84.18%   +0.05%     
==========================================
  Files          73       74       +1     
  Lines       13920    13996      +76     
  Branches    13920    13996      +76     
==========================================
+ Hits        11710    11782      +72     
+ Misses       1422     1418       -4     
- Partials      788      796       +8     

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

[ss2165]

1. Really like the petgraph use
2. A test of controlflow would be good since that has an alternative logic path
3. Should these functions be impls on SiblingGraph or HugrView?

[ss2165]

"attending to visiting"? worth rewording

[ss2165]

is this testing that hierarchy sibiling order doesn't matter? worth a comment

[doug-q]

3. Should these functions be impls on SiblingGraph or HugrView?

I think it is reasonable to consider adding children, children_postorder, recursive_children, recursive_children_postorder to HugrView, and children, children_postorder to SiblingGraph.

It is unclear whether those functions should take a node, or perhaps multiple variants should be added, with and without the node.

The name children already clashes with a method on HugrView, and it is far from clear that the naming scheme is the right one.

My view is that we should not add them at this time, until we are more certain. I will add comments to this effect, lmk if you disagree.