Introduce next-generation Python bindings using nanobind

[ManifoldFR]

This (draft) pull request adds a second set of Python bindings (under the provisional module coal.v2, with extension coal_pywrap_v2) using the modern nanobind bindings generator.

The new nanobind-based API can be imported as a replacement for the old one by importing:

import coal.v2 as coal

Task checklist

• Ensure no collision with previous set of Boost.Python bindings
• Stubs
• Re-expose the following features from the Boost.Python bindings:
  • Version
  • Broadphase (python/broadphase/broadphase.cc)
  • GJK (python/gjk.cc)
  • MeshLoader
  • Maths (python/math.cc)
  • Pickling
  • Serialization
  • Contact patches
  • Distance API (python/distance.cc)
  • Octree (python/octree.cc)
  • Collision (python/collision.cc)
  • Collision Geometries (python/collision-geometries.cc)
    • Base class
    • BVH models
    • Heightfields
    • CollisionObject
• Test everything

[florent-lamiraux]

For your information, after a quick test based on https://stackoverflow.com/questions/8233252/boostpython-and-weak-ptr-stuff-disappearing, nanobind seems as bad as boost python to handle weak pointers.

[ManifoldFR]

For your information, after a quick test based on https://stackoverflow.com/questions/8233252/boostpython-and-weak-ptr-stuff-disappearing, nanobind seems as bad as boost python to handle weak pointers.

Thanks, this is good to know in the future. Almost certainly, weak pointers will be an object management nightmare whatever the bindings generator is.

Anyhow, there is a definite advantage of upgrading our bindings, namely simplifying maintenance, getting modern features (and up-to-date docs), eliminating the Boost.Python dependency, ability to use the Python 3.12+ stable ABI - which are things Boost.Python simply doesn't have and never will 😃