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).

• A bug caused by numerical accuracy shapely/shapely#1871 - the intersection of two non-overlapping polygons with almost coincident linework produces an obviously incorrect result

• Union and Intersection Degenerate Case JuliaGeo/LibGEOS.jl#166
• Opposite intersection and difference results libgeos/geos#942
• BUG: polygon intersection sensitive to winding order since GEOS 3.10 libgeos/geos#827 - possibly same cause?
• BUG: intersection of polygons is sensitive to order libgeos/geos#741 - possibly same cause?
• One Voronoi cell created from a set of 10 points is non-convex libgeos/geos#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
• Polygon disappears in unaryUnion libgeos/geos#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 (shapely/shapely#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: #951 - mentioning it here for visibility just in case it is related.