Answer the PostGIS operators soundly from a multi-entry key

[estebanzimanyi]

The operator class geometry_mgist_ops_2d carries &&, which PostGIS answers on the bounding box of a geometry, so the whole geometry is the first key a value extracts and every operator answered on that box is witnessed by a key of the value. A query box meeting the box of a geometry in a gap between its members is answered by that key, where a key covering only a member leaves the row unreachable.

Each member of a multi-part geometry is a key of its own, kept whatever its dimension, so the point of a GEOMETRYCOLLECTION(POINT, POLYGON) carries an entry alongside the polygon; lwcollection_extract with a self-discovered type keeps only the largest dimension. The type decides which geometries have members, so the rings of a curve polygon and the arcs of a compound curve stay part of the single geometry they bound, a distinction the lwtype_is_collection predicate does not draw. A value that extracts a single key hands back a palloc'd array holding it, which the caller reads after the extract method returns.

Against PostgreSQL 18.3 and PostGIS 3.6.3, two hundred query boxes over two hundred and forty geometries whose members lie far apart match 2000 pairs sequentially, and the multi-entry scan reaches all 2000 of them and invents none. The regression tests in contrib/postgis/sql state those counts for a multi-entry scan and a sequential scan and read the sequential count as positive, so the comparison cannot hold vacuously. cmake --build <dir> --target installcheck runs them against a server holding the installed extension.