Fix handling of GeoJSON Z and M coordinates

[s3cur3]

Per the discussion on #171, there's an existing bug in our handling of Z and M coordinates in the GeoJSON decoder.

GeoJSON does not recognize any such geometry type as PointZ, LineStringZ, etc. Indeed, if you give these to PostGIS, you'll get an error. However, when GeoJSON types such as LineString are given with the 3rd position present in coordinates, we should assume it is Z, as the spec indicates, and parse it into the correct 'Z' type. This means that a LineString GeoJSON could be decoded into either Geo.LineString or Geo.LineStringZ, depending on the data.

Rather than making this a breaking change, I think we could maintain backward compatibility with past versions of geo by continuing to accept the Z-variant types, as long as we also accept 3-position coordinates as Z types as well.

Since GeoJSON has no notion of an M coordinate, we should continue to strip out 4th or greater positions on GeoJSON decode, such as 'M'. Decode 4+ member coordinates into 3 member 'Z' types.

[s3cur3]

At this time, I don't have a professional use for Z and M coordinates, so I'm rather loathe to make big changes here without knowing the real-world use cases. If somebody has a stake in this, I'd love to hear your thoughts on how to handle it.