Sometimes you don't want to compact a tree until all nodes have been inserted. w

For completeness sake, might as well implement IntoIterator which consumes the inner nodes and returns owned values.

The reexport is causing problems for at least one user of the crate. Also, it seems like reexporting crates is not as recommeneded as it used to be?

Starting with a theoretical example: we have a hex tree with nothing but res15 cells. Visiting them takes 15 pointer dereferences to from their respective res0 root cell. We can change that to a single pointer deref if we adding the concept of "skipping" to nodes.

Major goal: it would be awesome it we could both construct a compacted tree and drain it to a vec faster than calling libh3's compact() function. My gut feeling is the bottle neck currently lays non-deterministic alloction of behavior of a hexset. I do have a PR that improves things, but it probably needs some work. See #4

With compaction, a value returned by get() may be associated with a parent cell of one originally insert()ed.

Set/maps should implement .iter[_mut]() which returns an iterator over all cells.

Note to potential implementor: Nodes do not store their keys (cells). It's not necessary, since the structure mimics the semantics of H3. We'll need to reconstruct cell values as part of the tree walk. I suspect this could be a pretty big bottleneck, but it's better than the larger performance hit we'd incur if nodes did store a copy of their cell.

There's another H3 crate now, and prescribing a particular crate's H3 cell/index type seems overly restrictive.

CC @madninja