Parse MobilityDB's vendored pgtypes headers into the catalog

[estebanzimanyi]

MobilityDB keeps the PostgreSQL 18 base types in a pgtypes/ library at the repo root and
installs pgtypes.h and the pg_*.h set into the include prefix, so they are as public as
meos.h. run.py parses a single header root, so the two roots callers pass carry different
surfaces:

• an installed prefix holds the pgtypes headers alongside the meos*.h set, so they are parsed;
• the source tree keeps them outside meos/include, so a catalog derived from there loses the
  whole base-type surface — interval_make, the base type I/O functions, and the rest.

One MobilityDB commit therefore yields two different catalogs depending on the root. In
provision-meos the root follows build-libmeos, so a binding sees the full surface in a
workflow that builds the library and a smaller one in a workflow that does not, and compiling
against the smaller one fails on a symbol its own library exports.

This resolves the public pgtypes headers from MDB_SRC_ROOT — the root the @ingroup scan
already uses — and parses them alongside the header root, skipping any name the root already
provides so an installed prefix is unaffected. pg_config*.h carry PostgreSQL's build
configuration rather than API and stay out, matching the install set in MobilityDB's
meos/CMakeLists.txt.

Against MobilityDB master f3929ed5b the source-tree catalog grows from 4569 to 5338 functions,
interval_make among them as api: public, and the header set is the 11 files the install
places. The test suite goes from 5 failures to 2 across test_object_model.py and
test_struct_layout.py: Span, STBox and TInstant now resolve real field offsets, because
the vendored headers give clang the real base types. The 2 that remain fail the same way on
master and reflect the approximate struct layout of the source-tree parse.