Advance the MEOS commit and regenerate the UDF surface

[estebanzimanyi]

Advance the MEOS commit and regenerate the UDF surface

Take the trailing borderInc of every grid function MobilityDB declares with it

valueTiles, timeTiles and valueTimeTiles over tbox, timeSplit over every temporal type, and
valueSplit and valueTimeSplit over tint and tfloat take the trailing optional borderInc of their
MobilityDB declarations (timeSplit(temporal, duration, torigin, borderInc boolean DEFAULT TRUE)),
passed to the bool border_inc the MEOS grid functions take: true gives the cell holding the
upper border of the value or extent its own piece, false leaves it out. Each full form gains a
registration with a trailing BOOLEAN, the shorter forms keep answering as true, and a NULL
borderInc answers no tile and no split row, as the other arguments do. The bins table function
over the span and span set types reads it from its bind data the same way.

Why: the MEOS commit the vcpkg port pins adds bool border_inc to the tile, split and bin
functions (MobilityDB #2895), so the hand-written calls of src/temporal/temporal.cpp and
src/temporal/span_table_functions.cpp no longer compile against it, and the argument has to reach
SQL for a query to ask for false. The time split also states its border as MobilityDB does: the
last instant of a value on the lower bound of a bin is a piece of that bin rather than the end of
the previous fragment.

Witness: timeSplit(tfloat '[1@2000-01-01, 5@2000-01-05]', interval '2 days') answers 3 pieces
over the bins starting 01-01, 01-03 and 01-05, the last holding 5@2000-01-05 alone, and 2 with
borderInc false; valueTiles(tbox 'TBOXFLOAT X([1, 10])', 5.0, 0.0) answers 3 tiles and 2 with
false.

Measured: the extension builds against the pinned MEOS with no warning in the changed files. The
new test/sql/parity/025_temporal_tile_border_inc.test passes its 7 assertions, whose counts follow
from the rule before the run. Five assertions of 025_temporal_tile_split.test answer the border
instant as its own piece, each read off the bins it falls on, and one more states the false form;
the five 025 tile tests pass 83 assertions. Of the full suite, 3034 of 3039 assertions pass; the
other 5 are in tests this change does not reach: geoToH3IndexSet, which the regenerated surface of
the base no longer registers (h3_prefilter, container_comparison, set_declared_signature), and
asMFJSON over tpcpoint and tpcpatch (pointcloud_schema, tpcpatch).

Generate the H3 geometry functions whose resolution MEOS declares as int32

The H3 prefilter shape of tools/codegen_duck_udfs.py takes a geometry function's resolution as a
32-bit integer however MEOS spells it, int or the int32 of the SQL-exposed integer
convention, as the integer return check of the same file reads it. geoToH3IndexSet(geometry,
integer) and latLngToCell(geometry, integer) are registered again.

Why: the pinned MEOS declares geo_to_h3index_set(const GSERIALIZED *gs, int32 resolution) and
geo_to_h3index_cell likewise, and the shape matched the second parameter only as int, so the
regenerated surface dropped both registrations while the catalog still states each public with
its SQL name and its (geometry, integer) signature.

Witness: SELECT eEqual(geoToH3IndexSet(ST_Point(1, 1), 5), th3index('SRID=4326;[Point(1
1)@2000-01-01]'::tgeompoint, 5)) failed with "Scalar Function with name geotoh3indexset does not
exist" and answers again.

Measured: regenerating from the catalog of the pinned commit adds exactly the two registrations
and their bodies (Gen_geo_to_h3index_set, Gen_geo_to_h3index_cell) to the surface and changes no
other; h3_prefilter, container_comparison and set_declared_signature pass.

State the point cloud MF-JSON answers of the pinned MEOS

pointcloud_schema.test expects asMFJSON(tpcpoint) of a registered pcid to carry each instant's
point under "values", {"pcid":7,"pt":[1,2,3]}, beside its coordinates, and tpcpatch.test expects
asMFJSON(tpcpatch) of a pcid no schema states to report "PCSCHEMA for pcid 1 not registered", as
tpcpoint.test expects of the point of the same pcid.

Why: the pinned MEOS writes the point cloud value of every instant into its MF-JSON so that the
text reads back into the value (MobilityDB a362004728, "Read every temporal type back from the
MF-JSON it writes"), which MobilityDB's own 421_tpcpoint_mfjson expected output carries. Writing
the points of a patch decodes them through the schema of its pcid, so a pcid no schema states is
refused; reading a value needs no schema, writing its coordinates does. The patch test keeps
pcid 1 unregistered because a registered schema lives as long as the process the suite runs in,
and tpcpoint.test asserts that same pcid resolves to nothing.

Witness: asMFJSON(tpcpoint '2300000007...@2024-01-01') answers
{"type":"MovingPCPoint","coordinates":[[1,2,3]],"values":[{"pcid":7,"pt":[1,2,3]}],...}.

Measured: with this and the two commits before it, the full suite passes 3066 assertions in 108
test cases.