Report a MEOS error as the exception JMEOS raises for it

[estebanzimanyi]

Call the topological and position functions by their class-prefixed names, unquoted

The topological and position functions of the generated SQL surface take the prefix of the class
whose values or bounding boxes they compare, the names the portable dialect chapter of the
MobilityDB manual gives: set, span, spanset, tbox, stbox and tpcbox, and the base type for same
(cbufferSame, npointSame, poseSame, posechainSame). Flink's parser takes each unquoted.

GeneratedSqlSurfaceTest.theClassPrefixedNameIsCalledUnquoted calls spanOverlaps over two float
spans built with floatspanFromText. TopologicalPositionSurfaceTest checks that the 31 topological
names are registered, calls every overload of the two families the surface registers, over values
read by their readers (FromText, FromHexWKB for a point cloud value, FromHexEWKB for a geometry and
a geography, a value with Z for the operators reading the third dimension, and the box of the
value beside it for a box argument), and checks that each answers a Boolean; it checks the known
answer of each operator over two spans, two time spans and two spatiotemporal boxes.

Witness: since MobilityDB 762b3501cc the engines call the overlap of two spans spanOverlaps, so
the generated surface registers no function overlaps and the test's call of overlaps(floatspan,
floatspan) fails validation: No match found for function signature overlaps(FloatSpan,
FloatSpan).

Measured over MobilityDB master 5e7da7e8d9 with the commits #2980, #2981 and #2984 merge, the
catalog of MEOS-API 18a1e6d53c, and JMEOS main with the commits #153, #154 and #155 merge: the
surface registers 999 SQL functions and 7709 overloads, the two families 95 names and 1809
overloads; the binding module passes its 21 tests and the benchmark module its 12, and the build
prints no warning.

Why: a binding calls a function by the name the portable dialect gives it, and every overload of
the surface answers.

Report a MEOS error as the exception JMEOS raises for it

Every call into MEOS goes through a GeneratedFunctions wrapper, which runs
GeneratedFunctions.ensureReady() first: that initialises MEOS once per process, installs
MeosErrorHandler as the error handler, and sets up the timezone and collation of the calling
thread. After the call the wrapper reads MeosErrorHandler.checkError(), which rethrows the error
MEOS reported as a typed MeosException carrying MEOS's own code and message. The wirings, the
benchmark programs and the tests therefore install no handler of their own, and the tests neither
initialise nor finalise MEOS: a handler installed over MeosErrorHandler records nothing, so
checkError() finds no error and a failed call answers false or NULL, and meos_initialize() puts
back MEOS's default handler, which ends the process. The wirings call the operator functions
directly, as the UDFs of MobilitySpark do.

The callback MEOS makes into the JVM to report an error runs through jffi's closures, and JMEOS
builds against jnr-ffi 2.2.14, so the binding and the benchmark use that version.

Witness: with jnr-ffi 2.1.10 (jffi 1.2.19), GeneratedFunctions.tfloat_in("garbage") ends the JVM
with SIGSEGV in the jffi closure stub; with jnr-ffi 2.2.14 it throws MeosTextInputError (22):
Missing delimeter character '@': garbage, and back_stbox_stbox over two boxes without Z throws
MeosInvalidArgValueError (12): The stbox must have Z dimension.

Measured over MobilityDB master 5e7da7e8d9 with the commits #2980, #2981 and #2984 merge, the
catalog of MEOS-API 18a1e6d53c and JMEOS main with the commits #153, #154 and #155 merge, on top of
#70: the binding module passes its 21 tests, TopologicalPositionSurfaceTest among them, and the
benchmark module its 12, and the build prints no warning.

Why: MEOS reports an error through the handler JMEOS installs, so the binding leaves that handler
in place and receives the error as the exception it raises.