Read MEOS's temporal types out of MEOS

[estebanzimanyi]

catalog_gen.go carries every temporal type MEOS declares, generated by
tools/codegen from the MEOS sources that define them: meos_catalog.c for the
names, each type's base and bounding box, and the predicates temporal_type,
tnumber_type, tspatial_type and temptype_supports_linear; type_out.c for
temptype_as_mfjson_sb, the switch that writes each type's MF-JSON token. The
table holds 23 types at MobilityDB master f301e14369.

tPropType is a projection of that table. A temporal property is a non-spatial
value, so the types it resolves are those MEOS writes MF-JSON for whose base
type OGC Part 1 gives a token to. That is keyed by base type, in ogcScalar,
because Part 1 defines four tokens and no more: every temporal type MEOS builds
over one of those bases is carried, and one over a fifth base is a question for
the standard rather than a line in this tier. tbigint is carried by that rule,
with the token MovingBigInteger that MEOS writes for it and the OGC token
TInteger its base int8 has, and the store gains the vbigint column, which an
ALTER adds to a table created before the type existed.

Two MEOS types then carry TInteger, tint over int4 and tbigint over int8, so
the token alone does not name a type. ogcCanonical names the one it resolves
to: Part 1's TInteger is a 32-bit integer, so a request naming it asks for
tint, and tbigint is the wider type MobilityDB adds over the same token.
Resolving such a token by whichever entry a map yields last picks a different
type from run to run, and a stored property is then read out of a column its
table may not have.

The value columns of mf_tproperty are likewise one per scalar type, named for
the type with a v where its leading t stands, so a type MEOS adds needs a
column of that name and nothing else.

catalog_test.go holds the generated table and the standard's vocabulary in
step: every non-spatial type MEOS writes MF-JSON for over a base the standard
names must resolve, and resolve to the MEOS type and the MF-JSON token the
table carries; no spatial type may resolve, since a spatial value is a moving
feature's geometry rather than a temporal property; every OGC token resolves to
exactly one type, through ogcCanonical where several carry it; and the store's
columns are one per scalar type. A temporal type MEOS adds over one of those
bases arrives as a failing test rather than as a request the tier rejects at
run time.

The build job regenerates the table against a MobilityDB master checkout and
refuses a difference, which is what keeps the committed copy current: a
hand-kept table goes stale in silence, and this one cannot.

GENERATION.md records where each fact is read from, and why the generator reads
the C sources rather than the MEOS-API catalog: the catalog states no MF-JSON
token, and its typeRelations.byBase holds one temporal type per base, so it
carries trgeometry for the base pose and drops tpose, which shares it.