Run every MEOS test in every build (stacked on #35)

[estebanzimanyi]

Name every facade method by the class the catalog puts it in

The MeosOps* facades are grouped by the catalog's object model, which gives a
class to every base value MEOS passes by reference: geom_in belongs to
Geometry, the cbuffer, npoint and pose constructors and accessors to Cbuffer,
Npoint and Pose, geo_as_text to Geo. The smoke tests call those methods on the
free-function classes, MeosOpsFreeGeo, MeosOpsFreeCbuffer, MeosOpsFreeNpoint and
MeosOpsFreePose, which hold none of them, so the binding module's tests do not
compile against facades generated from the current catalog. Each call names
the class that holds the method.

The wiring javadoc names methods the same way: edwithin_tgeo_tgeo is on
MeosOpsFreeGeo, and the windowed-tier examples use tpoint_length and
tnumber_twavg, the MEOS functions for a trajectory's length and a temporal
number's time-weighted average.

Run every MEOS test in every build

Five test classes carried @EnabledIfSystemProperty(named = "meos.enabled"),
so a build without the property reported each of them as skipped under a
green conclusion. Each class runs in every build and needs a libmeos on the
load path, which CI and tools/refresh-from-master.sh both supply. The
meos.enabled property gated nothing but those classes and the full-matrix
test's choice of Q5 count, so it leaves the pom with them: the three Q5
expectations are the MEOS geodetic engine's answer, 0, and the comment
keeps the pure-Java scaffold's counts beside the open reconciliation.

The demo topology and the wiring README name the switch the generated
runtime reads, mobilitykafka.meos.enabled (MeosOpsRuntime). The facade
smoke test said the family smoke tests compile only under family build
flags that nothing implements; that statement goes.