Add Gosper island boundary edge iterator

[ajfriend]

Closes #1114

Adds IterEdgesGosper, an iterator that yields the directed edges forming the boundary (Gosper island outline) of a cell's child set at a given resolution.

• Each edge's origin cell is a child of the parent cell; its destination cell is not
• Edges form a closed counter-clockwise loop
• For a parent at resolution r expanded to child resolution R: hexagons produce 6 * 3^(R-r) edges, pentagons produce 5 * 3^(R-r)
• For now, this is an internal-only iterator, not included in the public API

Usage

IterEdgesGosper iter = iterInitGosper(cell, childRes);
while (iter.e) {
    // iter.e is the current directed edge
    // iter.remaining is the number of edges left
    iterStepGosper(&iter);
}

Next step: Speed up cellsToMultiPolygon

This is a building block for a faster cellsToMultiPolygon. When given a pre-compacted input cell set, the iterator allows the cellsToMultiPolygon algorithm to walk the Gosper island boundary edges directly, skipping all internal edges. On a Colorado polygon at resolution 8, this yields a 35x speedup. The higher the resolution, the better the speedup. This speedup is separate from the 3-4x improvement already achieved with the new cellsToMultiPolygon algorithm.

[coveralls]

coverage: 99.081% (-0.01%) from 99.095%
when pulling d96092e on ajfriend:gosper_iter
into 1d5346b on uber:master.

[ajfriend]

Talk explaining how this fits in: https://ajfriend.com/h3c2p-talk/

[isaacbrodsky]

You could also write this with type Direction and use I_AXIS_DIGIT, etc.

[ajfriend]

Yeah, that's better. Updated.

I left some comments on the numeric sequence, because I think that makes it easier to see the shared pattern.

[isaacbrodsky]

This checks that the new cell is different but not necessarily unique (i.e., the iterator could swap between two different values and still pass this test). The comment on this function implies a more involved test that the same value will not be returned twice.

I guess this is handled practically by do_edges_connect/check_expected_edges?

[isaacbrodsky]

I think these should have t_assertSuccess?

[isaacbrodsky]

guard with t_assertSuccess?

[isaacbrodsky]

note: it would be nice if we could paste this list into h3geo.org and see the edges visualized alongside the cell

[isaacbrodsky]

I wonder if it could be possible to fast-forward to the next non-deleted edge, as an optimization.

I guess it's possible we start somewhere in the middle of the deleted subsequence, in which case it would probably be harder to compute how to get out of it in a single step.