zero copy coordinate transformer when not reprojecting?

[springmeyer]

The solution to #116 was to add a "skipping transformer" such that when using a strategy that could return false we'd skip these coordinates and continue on. The context is that proj4 may fail and therefore if used in a strategy would return false.

Okay, so then a followup fix of #121 added another case where the strategy could return false: when totally wacky coordinates (like from some overflow in the separate tool that created the geometry) get passed into the processor and are out of range for the angus clipper. Despite this being really oddball and rare - because it happened in production at Mapbox - I added this as another "skippable" case.

Now we need to think about optimizing. I'm seeing that:

• when not reprojecting
• we could clamp instead of skipping for out of range coordinates
• and then in this case the skipping transformer could be replaced with an in-place transformer
• therefore you'd be able to safely apply the transformation strategy on all coordinates without ever needing to skip and this could be zero-copy and therefore faster
• However: the problem is that the input geometry is double and the output is int64: hmmmm

[springmeyer]

However: the problem is that the input geometry is double and the output is int64: hmmmm

This is a showstopper. Technically int64 and double use the same space so you could reinterpret_cast to change the values in place, but that is far from a good/safe idea. Closing. Let's focus on optimizations like #126 first.