Polyfill Improvements

[pocketken]

• support filling of GeometryCollections (meaning any of POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON)
• look at whether or not it makes sense to use the NG geometry overlay. Initial quick stab at it shows that it breaks some of the existing polyfill tests, so dragons likely ahead
• add test cases for current open upstream/elsewhere polyfill bugs to see if we're good or if there's anything that needs to be fixed
  • upstream issue 521
  • h3-pg issue 56
• support for different CRS's? The upstream polyfill modes RFC PR makes specific mention of web mercator (3857), however I imagine there's use cases for others as well (maybe 4978?). This should be trivial to support using ProjNet, however, we don't currently expose any way of transforming vertex coordinates prior to containment checks (we're always using the WGS84 lon/lats produced by GeoCoord). This also means anyone trying to use .Fill() right now on a polygon that is not in WGS84 is getting incorrect results.
  • also need to fix the polygon split functionality to support non-WGS84 (or perhaps just don't worry about splitting it if a transform is provided..? or maybe we just expose SplitGeometry as a utility extension and leave it up to the caller to split if using transmeridian geometry..?)
• maybe we should also provide an overload that takes a delegate? That way the user is free to use whatever predicate(s) they want in order to satisfy inclusion of a particular index boundary, e.g. something like Func<Geometry, Geometry, bool> would allow you to do (polygonBeingFilled, cellBoundaryToTest) => polygonBeingFilled.Crosses(cellBoundaryToTest) or .Intersects() and so on. Maybe pass the index being tested as well?

Whatever we do to support CRS transforms in Fill should be extended to any of the other geometry-producing methods as well for consistency.