Document provision-meos onboarding for bindings

[estebanzimanyi]

GENERATION.md gains a "Consuming MEOS from a binding (provision-meos)" section: how a binding derives the MEOS catalog and libmeos in CI from a single MobilityDB commit via the shared provision-meos composite action, instead of committing a meos-idl.json / libmeos.so snapshot that drifts.

It documents:

• The principle: a binding records the MobilityDB commit it targets and derives the catalog (and, for native/FFI bindings, an installed libmeos) in CI. One coordinate in, catalog and native library out from the same ref — zero drift.
• The live action interface (inputs mobilitydb-ref / build-libmeos / families, outputs catalog-path / libmeos-prefix) and a copy-pasteable minimal CI recipe (resolve the source commit, provision, optionally cp the catalog into place, run the binding's own generator + tests).
• The pinned-SHA (reproducible) vs master (track-latest) ref choice, both drift-free.
• Two archetypes with proven worked examples: catalog-deriving (MobilitySpark Carry Doxygen @param[out] through the catalog as shape.outParams #37, JMEOS Document provision-meos onboarding for bindings #44) vs libmeos-only native/FFI (MobilityFlink Resolve the array-return element type in the catalog shape #41, MobilityKafka Attach the doxygen module group (@ingroup) to the catalog #21).
• A one-line "adding a new binding" checklist so MEOS.js / PyMEOS / GoMEOS / MEOS.NET / meos-rs can adopt it mechanically.

Documentation only — no change to the action, run.py, or any workflow.