Parse the headers an install of MEOS ships, without the GEOS stand-in

[estebanzimanyi]

MobilityDB's header tree holds geos-none/geos_c.h, a stand-in for GEOS's
header that its build reads only where GEOS is absent, and installs then in
place of GEOS's own geos_c.h, so no installed header tree holds both. Read
beside the system geos_c.h that meos_internal_geo.h includes, each of its
three enums is a redefinition clang drops: it enters the catalog as enum
(unnamed at .../geos_c.h:84:6) or one of two more, with no value, beside 11
GEOS functions listed as MEOS core functions, and JMEOS FunctionsGenerator,
which writes one Java enum per catalog enum, fails opening a file of that
name. meos_headers is the one list build_entry_point includes and
parse_meos owns: the tree's headers less the stand-in directories, the set
an install of MEOS ships.

Witness: tests/test_stand_in_headers.py reads a tree holding a stand-in
directory and a header named like it elsewhere, and asserts on the
generated catalog that every enum is a C identifier with values and that no
function, structure or enum comes from geos_c.h. The catalog of MobilityDB
ebf26ad0da fails both catalog assertions without the change.

Measured on MobilityDB ebf26ad0da, the source-tree catalog with and without
the change: enums 33 to 30, functions 6558 to 6547, the 3 enums and the 11
GEOS functions of geos_c.h removed and nothing else changed but the counts
that follow from them (internalFunctions 2691 to 2680, the object model's
unclassified 4117 to 4106). No binding names any of the 11 GEOS functions.
JMEOS main (7773691c) compiles with the new catalog, writing 29 of its 30
enums, and fails on enum (unnamed at .../geos_c.h:84:6) with the old one,
as its Deploy Javadoc run 38269821321 does. The suite reads 522 passed, 26
skipped and 3 failed; the same 3 fail without the change.

Why: the catalog states MEOS's API as an install of MEOS ships it, and a
stand-in for another library's header is that library's API.