Get rid of insertBehind

[treeowl]

It's extremely slow, breaks on union, and relies in a brittle fashion on the exact implementation of minView. Let's be rid of it! The operation makes much more sense in priority queues based on finger trees, where the elements are stored in insertion order and the structure is annotated with subtree minima. (Specifically, a 2-3 finger tree whose digits can be 0 or 1 should do the trick).

[treeowl]

Serious question: does this function even work at the moment? I have no idea if the new deletion implementation satisfies its brittle needs. If not, we may need to make a make a major release next just so we can kill this thing. It should never have gone in to begin with.

[treeowl]

Maybe I've been unfair. I thought this broke on union, but maybe it doesn't. And I haven't been able to break it (yet) with the new deletion function. So... maybe it's okay? It's really slow though!

[treeowl]

I just don't like how brittle it is. Every single operation in the module has to be written to preserve the order of insertBehind even though the module header explicitly documents unstable ordering. If it were fast, that might be worth doing (for stable sorts), but it's not, so I'd much rather not have that landmine.