Remove GeoMultiPolygon since it is not used

[ajfriend]

Or is there a reason to keep this in h3api.h?

[coveralls]

Coverage remained the same at 98.92% when pulling 8fad017 on ajfriend:geomulti2 into 3f92cb8 on uber:master.

[ajfriend]

Alternatively, we could get rid of all the LinkedMultiPolygon functions/structs (really, just not expose them in the public API), and just expose the arguably cleaner GeoMultiPolygon struct and associated functions publicly.

We would just need to write an (internal) function to convert from LinkedGeoPolygon to GeoMultiPolygon, and provide a public destroyGeoMultiPolygon() function.

[isaacbrodsky]

Can this be merged after v4.0.0 is released?

[ajfriend]

Can this be merged after v4.0.0 is released?

I think it depends on what we think the ideal end state would be (the public-facing data structure as LinkedMultiPolygon or GeoMultiPolygon), and if/when we'd want to remove the other "deprecated" functions.

Apologies for coming up with another issue before 4.0, but I didn't see this stuff until I started using the new API in the Python bindings. I mostly wanted to flag this for discussion. I think here are benefits here, but I'm not sure if they outweigh the cost of delaying...

And correct me if I'm wrong, but I think using GeoMultiPolygon would greatly simplify the implementations in the bindings.
I'm guessing each of the bindings essentially implements their own linked list walker to do LinkedMultiPolygon_to_GeoMultiPolygon. We could move all of that common code to the C bindings, and I'm guessing that function shouldn't be too hard to (re)write in C.

Also, we can reduce the API surface area by removing the Linked* data structures, which I think could be confusing to users. The Linked* stuff feels like it should be hidden as an implementation detail.

[ajfriend]

And I'm guessing that was the intention behind GeoMultiPolygon, but we just never got to completing that work.

[ajfriend]

Oh, but maybe there's a potential speed benefit in avoiding the translation to non-linked data structures, so maybe it makes sense to keep both interfaces?

[isaacbrodsky]

We discussed offline; I understand we will not block v4.0.0 on this change. We might just use this structure soon after releasing v4, or we'll consider removing it after the v4 release as no function is consuming/using/producing this structure.

@nrabinowitz @ajfriend

[isaacbrodsky]

#681