Render the compositions the catalog states on the typed SQL surfaces

[estebanzimanyi]

Both typed surfaces register every composition of the catalog's top-level compositions beside
the signatures of its functions, through one list _sql_overloads yields for both engines. An
operand is decoded as an argument is and passed through the MEOS functions of its casts, a value
operand passes its literal, and the function call takes the operands in the order of its C
parameters. A composition without a call answers the last cast of its operand; a restore
answers the argument at the time of the call's answer; a set-returning composition reads its
rows through the columns of the call's own set-returning signature and restores the column it
names in each row, and one returning an array reads the elements the call writes, as
_signature_overload reads an array return.

Witness: over MobilityDB e30ef41657 and MEOS-API 0438baabc6 the catalog states 335
compositions, the relationships of tpose, tnpoint, the cells and the point clouds through a
cast, expandSpace and the grid functions of tpose and tpcpoint among them, and neither surface
registers any: eDisjoint(tpose, geometry) does not exist on Spark.

Measured over the same pair: all 335 compositions render; both engines register 8627 overloads
where main registers 8231, 164 of them set-returning signatures where main has 144, the refusals
of main's signatures unchanged. Through MobilitySpark's typed surface eDisjoint(tpose, geometry)
answers true for a pose trip from Point(1 1) to Point(2 2) against Point(10 10), and spaceSplit
of that trip in tiles of size 1 answers 2 rows whose tpose column is the trip restricted to the
time of its tile.

Why: a composition is a function the catalog states in steps every step of which is a public
MEOS function, so both engines answer it as PostgreSQL does without reading SQL.