State the SQL argument order through the kernel a wrapper and its function share

[estebanzimanyi]

A wrapper and the MEOS function a signature names can meet at a shared kernel rather than one
calling the other: Distance_value_set, the wrapper of setDistance(integer, intset), reads the
value first and calls distance_set_value(s, value), and distance_set_int(s, i) calls the same
kernel over s and its integer converted. parser/boundargs.py reads the order of the SQL arguments
through that kernel where the wrapper does not call the function: a parameter of the function
carries the SQL argument the wrapper passes at the kernel position where the function passes
that parameter, the kernel being the first callee of the function's body the wrapper calls with
as many arguments. The bodies come from the documented MEOS definitions, read with the pattern
the parameter lists are read with.

Witness: over MobilityDB master 4c4457d2ec the catalog states no order for
setDistance(integer, intset), whose wrapper reads the value before the set while
distance_set_int takes the set first, so the typed Spark and Flink surfaces refuse it as
"arg:integer/Set *" while they register setDistance(intset, integer); so for the value-first
forms of setDistance, spanDistance and spansetDistance over the five base types, and the
number-first forms of nearestApproachDistance over tint, tbigint and tfloat and of tDistance
over tint and tfloat.

Measured over MobilityDB master 4c4457d2ec and the installed headers of a libmeos built from it:
104 orders other than the C order, from 84, the 20 added being those signatures, each stating
the value or the number first; the catalog differs from master's in these fields alone. The
typed surfaces JMEOS main generates from it register 7433 overloads, from 7415, the 18 added
passing the value first; the integer forms of nearestApproachDistance follow the float result
of JMEOS #150. The suite passes, 25 tests skipped as on master, tests/test_boundargs.py stating
the kernel order, the kernel in the C order and the function without its body on synthetic
bodies, and nearestApproachDistance(float, tfloat) over the generated catalog.

Why: where the wrapper and the function call one kernel, the kernel call is where each pairs
its arguments, so the catalog composes the two.