Take the JVM generator from JMEOS rather than vendoring it

[estebanzimanyi]

codegen_jvm.py emits calls into functions.GeneratedFunctions, the class the
JMEOS jar carries, so JMEOS owns it and a copy here goes stale the moment that
surface folds an out-parameter or widens a return. It now arrives the way the
catalog beside it does — staged by the refresh chain from GENERATOR_DEST, and
by CI from the jmeos/ checkout the workflow already makes for the jar — and
is gitignored, so the tree holds no copy to go stale.

The copy this repository carried lagged JMEOS's by 202 lines, so the surface
GAINS what that copy never emitted: eDwithinPairs, aDwithinPairs,
eIntersectsPairs and aDisjointPairs, the folded NxN operators, appear in the
generated facades for the first time. codegen_spark_udfs.py is staged with it
— the spark arm loads it from the generator's own directory, so the two are one
unit, and --engine spark here answered FileNotFoundError naming the absent
sibling rather than generating.

A full tools/refresh-from-master.sh with the vendored copy deleted stages both
files from JMEOS, generates from them, and builds green: 7 binding and 12
benchmark tests, BerlinMODSetSetJoinTest and BerlinMODBenchmarkTest among
them.