Add support for simplifying a polygonal coverage with the JTS/GEOS method

Using the GEOS method would imply that a whole layer fits into RAM. This is probably reasonable for 90% of use cases, but would break for remaining 10%.
Accepting that limitation (the alternative would likely require going through building a database with topology), that could be a gdal vector pipeline filter:
gdal vector pipeline read my.gpkg ! coverage_simplifier --tolerance X | write out.gpkg
where the filter would accumulate all input features in RAM, run GEOSCoverageSimplifyVW_r(), and then return all simplified features to the later stages

(CC @dbaston as he may have some familiarity)

I've had this on my mind for a little while. It seems a fair bit of work to do cleanly (even if reading everything into memory) because LayerTranslator::Translate is really set up to work feature-wise. Also, you don't necessarily need to read all input features into memory - you can read N features, do a coverage simplification while preserving the external boundary (https://github.com/libgeos/geos/blob/e1c9a7c5c6819383bb57fb15a000cdb06dd47600/capi/geos_c.h.in#L3998) write them, and continue. Of course, the boundaries between batches don't end up getting simplified. To get reasonably-defined chunks you'd want to sort or cluster the envelopes of your inputs, which would imply reading the inputs twice.

It seems a fair bit of work to do cleanly (even if reading everything into memory) because LayerTranslator::Translate is really set up to work feature-wise

I wasn't considering using ogr2ogr for that, but a new filter under the gdal vector pipeline framework, where we can do one thing at the time. This will be a bit less optimized that ogr2ogr, but much more maintainable and predictable for users regarding into which order operations are done. like gdal vector pipeline read ... ! coverage_simplifier ! reproject ... ! write vs gdal vector pipeline read ... ! reproject ... ! coverage_simplifier ! write

do a coverage simplification while preserving the external boundary (https://github.com/libgeos/geos/blob/e1c9a7c5c6819383bb57fb15a000cdb06dd47600/capi/geos_c.h.in#L3998)

That's cool

To get reasonably-defined chunks you'd want to sort or cluster the envelopes of your inputs, which would imply reading the inputs twice.

this calls for a "spatial_sort" filter :-)