Carry a bytea on the typed SQL surfaces

[estebanzimanyi]

The typed Spark and Flink SQL surfaces of tools/codegen_jvm.py carry the SQL type bytea as a
Java byte[], BinaryType in Spark and BYTES in Flink. A byte array a function reads,
shape.inputArrays over uint8_t with its length in another parameter, is the bytea the SQL
argument holds, which the jar copies with its length (span_from_wkb(byte[])); a byte array a
function returns, its length in a size out-parameter, is the byte[] the jar copies out of the
buffer MEOS allocated and frees. The FromBinary and FromEWKB readers, the
_send writers, the raquet reader over bytes and the raster tile value over pixels are
registered.

Witness: over the catalog MEOS-API 18a1e6d53c derives from MobilityDB master e464861d66, the
surfaces generated by main register no reader from a bytea and no writer to one, refusing
tfloatFromBinary(bytea) and its siblings as "arity:jmeos", the jar's one byte[] against the
two C parameters, and temporal_send(tfloat) and its siblings as "ret:bytea/uint8_t *". With this
change the typed Spark surface answers asText(tfloatFromBinary(temporal_send(tfloatFromText(
'[1@2001-01-01, 2@2001-01-02]')))) with the value read, the same for a tgeompoint written as
EWKB with its SRID, an intspan and an stbox, and tfloatFromBinary(X'00') raises "Invalid
temporal type code in WKB string: 0".

Measured over that catalog and the jar it builds: both surfaces register 1128 SQL functions and
7852 overloads, from 999 and 7704, the 129 functions added being the binary readers and
writers and pixels and rasterTileValueQuadbin, and raquetRead gains its form over bytes; no
other generated file differs. No signature is refused as "ret:bytea" any longer, from 55, and
"arity:jmeos" falls to 30, from 183; the signatures it no longer stops reach the checks after
it, "sqltype:internal" (the binary receivers over internal) and "arity:sql".

Why: a bytea is how SQL hands bytes, and the jar already passes and returns them as byte[], so
a binding carries one as the other.