OverlayNG produces obviously incorrect results in some situations

[dr-jts]

This is an umbrella issue for various bug reports about failure cases in OverlayNG operations.

The cases always (?) involve nearly-coincident linework (either in a single input or between inputs). The result of overlay operations is obviously incorrect (i.e. it is drastically different from the expected result).

• https://github.com/shapely/shapely/issues/1871 - the intersection of two non-overlapping polygons with almost coincident linework produces an obviously incorrect result

  

• https://github.com/JuliaGeo/LibGEOS.jl/issues/166

• https://github.com/libgeos/geos/issues/942

• https://github.com/libgeos/geos/issues/827 - possibly same cause?

• https://github.com/libgeos/geos/issues/741 - possibly same cause?

• https://github.com/libgeos/geos/issues/955 - this is primarily a Voronoi algorithm robustness issue, but the way it manifests as an incorrect shape rather than a TopologyException is due to the noding correctness check failing

• https://github.com/libgeos/geos/issues/965

Previously an area-check heuristic was added in #812, but this does not handle all cases. Any fix should be tested to see if it handles the cases resolved by that fix (https://github.com/Toblerity/Shapely/issues/1216, GEOS-1144.

Options for fixing:

• add a heuristic sanity check based on the envelopes of the inputs (analogous to the heuristic area check). This will not catch all cases, however
• use a more expensive area-based check, utilizing the IntersectionArea approach. This should be (almost?) fully robust, at the cost of decreased performance

[grimsa]

There is one more issue with OverlayNG area heuristic check: https://github.com/locationtech/jts/issues/951 - mentioning it here for visibility just in case it is related.