ifcgeom: prototype OpenCascade kernel support for point/vertex representations

Exploratory proof of concept for #134, #1409 and #5218: IfcVertexPoint,
IfcCartesianPoint and IfcCartesianPointList3D used as top-level
representation items ("Vertex"/"Point"/"PointCloud") currently raise
"Failed to process shape" because AbstractKernel::convert_impl for
taxonomy::point3 is never implemented and point3 cannot appear as a
child of the generic items collection.

This makes point3/direction3 derive from geom_item instead of plain
item, so a lone point3 can stand in as a representation item, and adds:

- OpenCascadeKernel::convert_impl(point3): a single point becomes a
  TopoDS_Vertex wrapped in a TopoDS_Compound, as aothms suggested in
  #5218.
- OpenCascadeKernel::convert_impl(collection): a bulk fast path for a
  collection made up entirely of point3 children (e.g. a whole
  IfcCartesianPointList3D) that builds ONE compound with all vertices
  in a single pass, instead of paying the generic per-item conversion
  overhead (cache lookup, heap allocation, a separate Triangulate()
  call) once per point.
- mapping for IfcVertexPoint (as a top-level item) and
  IfcCartesianPointList3D.
- loose-vertex emission in OpenCascadeShape::Triangulate, since a
  vertex-only shape previously triangulated to nothing.

This directly tests aothms's "the overhead is enormous" concern from
#5218. Benchmarked on this machine (Apple M-series, Release build):

- Normal (non-point) geometry is unaffected: a 5178-shape real model
  processes in 4.48s before this change and 4.49s after (~0.3%, noise).
- The bulk fast path scales linearly and cheaply: ~0.5-0.9 us/point for
  an IfcCartesianPointList3D from 1k to 100k points (100k points in
  ~93ms total).
- With the fast path disabled (pure per-item conversion, i.e. the naive
  reading of "a TopoDS_Compound of TopoDS_Vertex" with no batching),
  scaling is still linear, not quadratic, but ~4-7x slower per point
  (~3.5-4 us/point at the same scale, 100k points in ~380ms).

So aothms's concern is real as a constant-factor tax from going through
full OCCT BRep objects (TopoDS_Vertex/Compound, shared_ptr taxonomy
nodes, per-item caching) rather than flat coordinate arrays, but it is
not the asymptotic blowup "enormous overhead" might suggest, and a
reasonably-scoped batching fast path narrows the gap substantially.
Given Bonsai already has a working, accepted Python-side bypass for
this (create_point_cloud_mesh / create_structural_point_connection_mesh
in bonsai/tool/loader.py and geometry.py), this is offered as a
proof of concept for evaluation, not a claim that it should override
the prior "something for 0.9" call.

IfcCartesianPointList2D ("PointCloud" in 2D) is intentionally out of
scope for this prototype.

Adds pytest coverage (no Catch2/C++ test harness exists in this
codebase) for all three representation types plus a 1000-point
round-trip/timing sanity check.

Generated with the assistance of an AI coding tool.

src/ifcgeom/kernels/opencascade/OpenCascadeKernel.h

@@ -142,6 +142,9 @@ public:
 	virtual bool convert_impl(const ifcopenshell::geometry::taxonomy::boolean_result::ptr, IfcGeom::ConversionResults&);
 	virtual bool convert_impl(const ifcopenshell::geometry::taxonomy::loft::ptr, IfcGeom::ConversionResults&);
 	virtual bool convert_impl(const ifcopenshell::geometry::taxonomy::sweep_along_curve::ptr, IfcGeom::ConversionResults&);
+	// Prototype for issue #134 / #1409 / #5218, see point.cpp.
+	virtual bool convert_impl(const ifcopenshell::geometry::taxonomy::point3::ptr, IfcGeom::ConversionResults&);
+	virtual bool convert_impl(const ifcopenshell::geometry::taxonomy::collection::ptr, IfcGeom::ConversionResults&);
 
 	virtual bool convert_openings(const IfcUtil::IfcBaseEntity* entity, const std::vector<std::pair<ifcopenshell::geometry::taxonomy::ptr, ifcopenshell::geometry::taxonomy::matrix4>>& openings,
 		const IfcGeom::ConversionResults& entity_shapes, const ifcopenshell::geometry::taxonomy::matrix4& entity_trsf, IfcGeom::ConversionResults& cut_shapes);