[Refactoring]: JTS Polygonizer instead of ShapeReader

[kwvanderlinde]

Describe the problem

In order to work around a bug in JTS's ShapeReader, we added the ReverseShapePathIterator that switches the order of subpaths returned by an existing PathIterator. Also built into it is some rudimentary point deduplication and removal of subpaths that don't form a ring as a result.

While this works, it is a few hundred lines of code to maintain and is not a very straightforward utility to understand, nor is it clear that the order of subpaths should be something we can rely upon. The point deduplication is also not very robust as it just tries to merge subsequent points together if they are closer than some hardcoded precision.

The improvement you'd like to see

I'd like to see us move towards the simipler ShapeReader.toCoordinates() to produce rings from a PathIterator, then build the full geometry with JTS's Polygonizer.

I would also like to see this logic captured in an easy-to-use method for converting from AWT Area to JTS Geometry as there are a few places that need this conversion now. E.g., that is as simple to use as this:

public static Geometry areaToJts(Area area) ...

Expected Benefits

• Individual geometry coordinates are easy to set to a precision governed by the precision model.
• The Polygonizer approach only require about a dozen lines of code instead of a couple hundred.
• We no longer need to make assumptions about the order of a PathIterator.
• Having a utility method for conversion will mean we don't have to worry so much about remembering one trick or another at the places we need the conversion done.

Additional Context

No response