Expose BrepLoop, BrepTrim, and face→edge topology in Python bindings

[jchkoch]

Description:

The Python bindings currently do not expose the Brep loop/trim/edge topology that exists in the underlying OpenNURBS data model. Specifically, the following are commented out in src/bindings/bnd_brep.h and not registered in src/bindings/bnd_brep.cpp:

BrepFace.Loops / BrepFace.OuterLoop / BrepFace.FaceIndex
BrepLoop class (LoopType, Trims)
BrepTrim class (Edge, IsReversed / m_bRev3d, TrimType, EdgeIndex)
Brep.Loops / Brep.Trims collections
BrepEdge.EdgeIndex, BrepEdge.TrimIndices(), BrepEdge.AdjacentFaces()

Without these, there is no way to determine which edges belong to which face in a multi-face Brep, what direction an edge is traversed relative to a face boundary, or whether a loop is an outer boundary vs. an inner hole.

The only current workaround is BrepFace.DuplicateFace(False), which creates an isolated single-face Brep copy — but this discards shared-edge identity between adjacent faces and doesn't provide edge traversal direction.

The native C++ functions for these already exist in src/librhino3dm_native/on_brep.cpp (e.g. ON_BrepLoop_Type, ON_BrepLoop_TrimIndex, ON_BrepTrim_Type, ON_BrepTrim_GetRevFlag, ON_BrepTrim_ItemIndex), so binding them should be straightforward.

Use case: Walking Brep face boundaries with correct edge ordering and direction for adjacency information, without relying on coordinate-based heuristics.

Environment: rhino3dm ≥ 8.17.0, Python 3.10+

[jchkoch]

@fraguada Decided to try simply exposing the functions to see if that was enough for my use case. It seems to work for my use case as such. Therefore, added the pull request #713.