Read a declaration's family from the guard it sits under

[estebanzimanyi]

A family's declarations do not all live in the family's own header. A shared
header carries some under #if <FAMILY>, which MobilityDB compiles out when the
family is off: meos.h holds rtree_create_tpcbox, sptree_create_tpcbox and
meos_initialize_pointcloud that way, and meos_catalog.h four more.

The classifier read only the path, so those came out CORE — the label that
means "always emitted". A binding gating on the field emits them into a build
whose headers never declared them and whose library never defined them, so the
wrapper fails to compile, or compiles and fails to link. Nothing reports it from
the catalog side, because CORE is exactly what an always-present function
looks like.

The guard is read first and outranks the path; the subdirectory and the
meos_<family>.h name answer as before. #else ends the family's region rather
than continuing it, since the alternative branch is the one taken when the family
is OFF. The tokens come from the published families list, so a family added to
MobilityDB's ALL list is read here with no edit.

Against MobilityDB 5d58fbc05f the catalog changes by exactly seven functions,
all of them POINTCLOUD-guarded — ensure_tpointcloud_temptype,
meos_initialize_pointcloud, pointcloud_basetype, pointcloudset_type,
rtree_create_tpcbox, sptree_create_tpcbox, tpointcloud_temptype — with no
function, struct, enum or macro added or removed and no other field altered
anywhere. That MEOS.js carries five of the seven in a hand-maintained exclusion
list, and is missing the other two, is the shape of the defect: the list is a
copy of this classification kept by hand, and it went stale when
sptree_create_tpcbox joined its rtree_ sibling.

The test asserts both directions — the seven land in POINTCLOUD, and the
unguarded sptree_create_stbox/sptree_create_tbox beside them stay CORE, so it
fails if the guard is read too widely as well as if it is not read at all.