regen: bump meos-idl.json to MEOS-API + regenerate extended types (supersedes #15)

[estebanzimanyi]

Summary

Retargets the JMEOS PR #15 "regen against MEOS 1.4" intent onto the post-#9 multi-module layout. PR #15 itself is structurally incompatible with the multi-module migration (it modifies pre-migration paths); this PR delivers the same FFI surface via the canonical MEOS-API → meos-idl.json → JMEOS codegen pipeline that the multi-module migration set up.

What this delivers

Replaces codegen/input/meos-idl.json (the core-only IDL on main) with the MEOS-API published meos-idl.json that includes the four extended temporal-type families absent from the previous input:

Family	Generated FFI entries added
tcbuffer	366
tnpoint	177
tpose	162
trgeo	204
Total	909

After regeneration, mvn -pl codegen exec:java -Dexec.mainClass=FunctionsGenerator reports:

Functions parsed: 2699
Written: jmeos-core/src/main/java/functions/GeneratedFunctions.java

Why this and not PR #15

PR #15 modifies src/main/java/builder/FunctionsGenerator.java, src/main/java/functions/functions.java, and src/main/java/builder/resources/meos.h — paths that PR #9 (merged) deleted and moved into the new multi-module layout. The rebase therefore fails with modify/delete conflicts on every commit.

This PR uses the canonical multi-module paths (codegen/input/meos-idl.json, codegen/src/main/java/FunctionsGenerator.java, jmeos-core/src/main/java/functions/GeneratedFunctions.java) and re-runs the existing codegen against the updated input. Same FFI surface; clean multi-module integration.

Stream-consumer impact

Stream-side consumers (MobilityFlink / MobilityKafka / etc.) can now base on MobilityDB/JMEOS:main directly once this lands, with full access to:

• All core MEOS 1.4 spatial functions (already on main: geog_distance, edwithin_tgeo_geo, eintersects_tgeo_geo, nad_tgeo_geo, tdistance_tgeo_tgeo, …)
• The 909 extended-type entries this PR adds — tcbuffer, tnpoint, tpose, trgeo

The 2 high-level wrappers (utils.spatial.Haversine.distance, utils.spatial.PointToSegment.distance) needed for per-event spatial-predicate sites are on PR #18 (OPEN, CI green), which stream consumers can stack on the fork branch estebanzimanyi/JMEOS:feat/spatial-haversine for the geodesic surface without merge-wait.

Local verification

$ export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
$ mvn -pl codegen test
[INFO] Tests run: 87, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

$ mvn -pl codegen exec:java -Dexec.mainClass=FunctionsGenerator
Functions parsed: 2699
Written: jmeos-core/src/main/java/functions/GeneratedFunctions.java

$ mvn -pl jmeos-core compile
[INFO] BUILD SUCCESS

87/87 codegen unit tests pass; jmeos-core compiles green against the regenerated output.

Supersedes

• PR Regenerate functions.java against the MEOS 1.4 split-header layout #15 — same intent, structurally compatible landing
• See PR Regenerate functions.java against the MEOS 1.4 split-header layout #15 comment for the diagnosis of why direct rebase was not viable