Deprecate insertBehind

[treeowl]

insertBehind does not interact in any particularly sensible way with merges. I don't have a lot of faith that it works in other cases at all—it's far too fragile. It's also too slow to be really useful.

First stage in #35

[konsumlamm]

Seems fine to me. It's weird to have a function that makes guarantees about the order of elements with equal keys, when all the other functions don't. I guess in most cases insert would suffice. At least no package on Hackage seems to use it (https://hackage-search.serokell.io/?q=insertBehind). I'm reluctant to entirely remove it any time soon though.

[treeowl]

I'm reluctant to entirely remove it any time soon though.

We've never had any tests to demonstrate that it works. Those tests will not be easy, since other operations in the module could potentially mess up the relative ordering. I don't want to support this function, and I want it gone ASAP. It belongs in a different data structure altogether—one with two "fingers" rather than one.

[treeowl]

To clarify what I said in my last comment, that one function puts a major maintenance burden on other functions (especially insert and minViewWithKey) without contributing much on its own. It also has no specified (or obvious) merge semantics, so it can't be used usefully with merges (which are the raison d'être of binomial queues). It's very expensive dead weight, and we don't even know if we've met the heavy maintenance burden.

[konsumlamm]

I think we don't have to consider deprecated functions too much when changing other functions. Just provide it as "it's there, maybe it works". I'm not against removing it at all, just not that soon.