Derive the enum type mapping from the catalog

[estebanzimanyi]

TYPE_MAP hand-wrote a row per enum, and a hand list goes short and goes stale in
both directions at once. It named 6 of the 14 enums the catalog declares, so a
parameter of any other one had no mapping and the wrapper came out as a TODO stub
reading unsupported param; and it carried 2 rows -- RTreeSearchOp and
errorLevel -- for enums the catalog no longer declares and no function names.

configure(idl) takes the SET from the catalog instead, the shape MEOS.NET's
tools/codegen.py states at its own ENUM_TYPES, whose comment gives the reason in
one line: taking the set from the catalog is what keeps a newly added enum from
arriving unmapped the way a hand list leaves it. An enum MEOS adds is mapped the
day it lands, and one it retires stops being mapped.

ENUM_GO_NAME stays and is now stated for what it is: a SPELLING map, not an
exclusion. It fixes only the names PascalCase would not produce -- interpType
reaches Go as the published Interpolation -- and emit_types reads the same
helper, so the two cannot disagree about a name. Its dead RTreeSearchOp row goes
with the others.

MEASURED: the flat surface goes 3563 -> 3580 wrappers and the TODO stubs 26 -> 9,
closing exactly the enum class -- IndexSearchOp 9 and SPTreeKind 8, which is 17 of
17. MeosPixType's 4 stay out because they live in meos_raster.h, which is not in
HEADER_FILES: the raster family is not generated at all, a scope decision this
does not touch. The 9 stubs that remain are other shapes entirely (float8, float4,
Oid, Numeric, SpaceSplit, SpaceTimeSplit, MvtGeom, meos_malloc_fn, a PoseChain
out-parameter).

The object layer follows to 1270 methods and 91 deferred. go build ./... over
all 12 packages, go vet ./types and the parity gate exit 0; a second generator
run reproduces the tree byte for byte. gofmt -l reads 14 files before and after
-- the flat output has never been gofmt-clean and this does not move it.