Add per-layer invalid_polygon_repair_scope option to repair clipped-and-quantised polygons

[geoneutrino]

(This code was created with AI assistance)

Problem

Repair polygon PR 908 corrected polygon errors after simplification but still there could be issues im complex geometries like holes in river deltas or coastal regions like Philippines mentioned in discussion 909
Polygons written to a tile can be GEOS-invalid even when the source geometry is perfectly valid and no simplification is applied.

Root cause

It is not the clipper. Feeding real ocean shapefile polygons through fast_clip and testing the result with GEOS, every sampled polygon came back valid. The invalidity is introduced afterwards, in TileBbox::scaleGeometry /scaleRing:
snapping float coordinates onto the integer tile grid (floor, plus the 4-point backtracking dedup) collapses near-coincident vertices and creates self-intersections and touching rings.

Today repair_multi_polygon() runs only when simplifyLevel > 0, i.e. only for geometry that simplification may have broken. Layers that are merely clipped and quantised — typically ocean/coastline shapefiles — are never repaired, so the
damage goes straight into the tile.

What this PR adds

• As a defnsive approach a new config option per layer is introduced "invalid_polygon_repair_scope" with default "simplified_only" (current code flow) and the new option "all" as superset: additionally repair polygons that were only clipped and quantised

• extend the area guard
  repair_multi_polygon() rejects a repair whose result is less than 50% of the original area, to avoid the catastrophic collapse that buffer(0) can cause on large multipolygons. For clipped-but-unsimplified geometry an upper bound is needed as well: a repair that grows the polygon has filled a hole, which means an island silently disappears from the map.
  That upper bound must not be applied to simplified geometry — simplification legitimately changes area in both directions, and enforcing the bound globally made things worse in testing (one Bangladesh z7 tile went from 5 to 20 invalid features). So repair_multi_polygon() takes a strictArea flag, set only when simplifyLevel == 0.

Results

verified with a complete planet build. All known effects, mostly holes in very complex river deltas, are fixed. no new visual effects introduced. Tests with setting the new option on the ocean layer fixes

• river deltas (Ganges / Bangladesh / Myanmar / Amazon / Saigon)
• coastline effects (Phillipines)
• complex lagoons (Venice, Belize)
  Tests with activating the option on ocean + water_polygons fixes also very minor effects like in a harbor in a Switzerland lake

No mentionable effect on performance when active for ocean and water_polygon layers

Scope / limitations

This is a repair pass, not a fix of the quantisation itself. It does not reach full validity in every case — the remaining class of failures needs true snap-rounding at tile-grid precision (GEOS GEOSGeom_setPrecision or an equivalent)
Touching quantisation would have been very big task and alternatively i didn't want to introduce libgeos, - not as a new dependeny and also not because of maybe licence implications as it is lgpl

[geoneutrino]

• tilemaker generates degenerate polygons not present in source #864 (degenerate polygons) — reproduced with the exact data and config from
  that issue. Without the option, the tile contains the reported zero-area ring
  (2316,3877) (2292,3877) (2303,3877); with "invalid_polygon_repair_scope": "all"
  the feature is dropped, which is the outcome @pnorman called correct in that
  thread. Note this only applies to layers that opt in — the default is unchanged,
  so tilemaker generates degenerate polygons not present in source #864 still reproduces out of the box. Making the zero-area case unconditional
  would be a reasonable separate decision.