Build the benchmark image in CI

[estebanzimanyi]

Nothing in this repository builds the benchmark image, which is how it came to
build a release branch of MobilityDB while the jar it runs is generated from the
catalog of master: no run ever executed those lines. Building it is the test, so a
workflow does. The job reaches the application jar through the same shared chain
the build job uses, since the image copies that jar in.

It runs on a change to the image, to what the image copies, or to this workflow;
on a push to main; and weekly. The weekly run is the one that matters — the image
tracks MobilityDB master, so it can start failing with nothing here having changed.

The first run of that job is what the image needs. -DALL=ON turns on the H3
family, which wants libh3-dev, and Debian bookworm carries no such package, so
the configure step ends H3=ON was requested but libh3 was not found. The image
now builds on the distribution MobilityDB's own meos.yml builds MEOS on, with
the dependency set that workflow installs: Ubuntu 24.04, which carries libh3-dev
4.1.0, plus geos, proj, json-c, gdal, xml2 and zlib. A -DMEOS=ON build needs
neither the PostgreSQL server headers nor GSL nor PostGIS, so none of the three is
installed any more. Measured in a container: that set configures -DMEOS=ON -DALL=ON cleanly and reports Including temporal H3 index.

A successful build still says nothing about which library the image holds, and
jnr-ffi resolves lazily, so a library missing a symbol faults at the call rather
than at load: no build and no link reports it. The job therefore asks the image. A
libmeos configured without -DALL=ON carries no ts2cell_in and no
tposechain_in, while the surface generated from the catalog of master names both;
temporal_merge is the positive control, so a check reading the wrong file fails
differently from one reading a narrow build. It also asserts the application jar
carries functions/GeneratedFunctions.class, which is why the image needs no
separate copy of JMEOS on its classpath.