Generate the GoMEOS flat FFI layer from the MEOS-API catalog

[estebanzimanyi]

Make GoMEOS a catalog-driven binding: the flat FFI layer is generated from
the MEOS-API catalog (meos-idl.json) and derived in CI, so no MEOS header
is parsed in this repository.

What this delivers

• tools/codegen.py emits the flat FFI layer into the repo-root functions
  package (mirroring JMEOS functions / pymeos_cffi.functions): every MEOS
  struct is an opaque handle, char* is marshalled as string via
  cstring_to_text / text_to_cstring, enums are typed ints, and C function
  pointers are *[0]byte — the JMEOS-flat convention, no array unpacking.
• A types.go type layer (opaque handles + catalog enums) is emitted only for
  symbols the wrappers actually reference.
• The build workflow provisions the catalog and the all-families libmeos from
  MobilityDB via the shared provision-meos action, regenerates functions/,
  fails if the committed generated code drifts from the catalog, then
  compiles the package against the installed libmeos and runs the
  portable-parity gate (29/29 bare names, all six families).
• The catalog is no longer committed — it is derived in CI; the generated
  functions package is the checked-in artifact.

The hand-written OO gomeos package is left in place; regenerating it too from
the catalog's objectModel is tracked as follow-up work.

[estebanzimanyi]

Depends on MobilityDB/MEOS-API#52. CI derives the catalog via provision-meos@master; with #52 the 10 h3index_* (and 5 sibling) public functions are attributed to meos_h3.h and the generated functions/ package includes them. Merging this before #52 lands leaves those 15 functions out of the derived package. Land #52 first.