Prototype out IntervalHeap or std's BinaryHeap with a comparator-based API

[Gankra]

This would allow a heap to be reinterpretted as min/max without affecting the consumer of the collection (no wrapping the data to redefine Ord). It may also be the future of searching in maps/sets. However Heaps are a good simple place to test the ideas out on.

See this PR for preliminary work done in the area. It got blocked on unboxed closures becoming more coherent, which is now the case.

Ideally comparators would be part of the type, with a default Natural Comparator that just uses Ord. A Reverse Comparator would also be useful, in the same vein as the Reverse iterator adaptor. We could also consider providing a Fake Comparator for wrapping PartialOrd impls unsafely.

Unboxed closures that return Ord should presumably work as Comparators.

CC @huonw @sellibitze @aturon @reem

[reem]

This could probably be done with a:

trait Comparator<T> {
    fn cmp(T, T) -> Ordering;
}

and a default type param to an implementation that just forwards from Ord on all the necessary collections. Then you just need a blanket impl for closures of the right type...

[Ericson2314]

It must be part of the type for unions (and other binary functions) to be safe and fast. Could Comparator<T> be an alias of Fn instantiated with the right arguments, or would that cause coherence issues?

[Gankra]

@apasel422 knocked this outta the park