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. This repository received a
copy, which is how three copies came to differ: the one that gains a feature
keeps it, and the others go on emitting the surface they emitted before.

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.
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
answers FileNotFoundError naming the absent sibling rather than generating.

The generated surface does not move: JMEOS's copy IS the copy this repository
carried, byte for byte, so the same catalog and jar yield the same 122 files. 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 4
benchmark tests, BerlinMODSetSetJoinTest and BerlinMODFullMatrixTest among
them.