Eliminate test flakes in recently-added heap tests

[jhump]

Perhaps the sift up/down ops inside the heap impl are not entirely deterministic? It seemed rather consistent in my tests, and has mostly been true in CI. And yet there were also these two failures 🤔:

https://github.com/bufbuild/httplb/actions/runs/8754637253/job/24026890423
https://github.com/bufbuild/httplb/actions/runs/8755567093/job/24029992149

So this adjusts the test to not care about precise order. Instead, it only cares about distinctness of the items picked.

Edit: source of non-determinism was use of a map inside the implementation of update, nothing to do with any non-determinism in the container/heap package.

[jchadwick-buf]

I'm a bit skeptical that the heap ops could play into this; the bin heap implementation in Go is very straight-forward and I don't think it should be non-deterministic at all. I think if anything it must be caused by map iteration order somewhere (range over newMap?) That said, if we're not picky about it being deterministic, no need to really think about it too much. LGTM.

(edit: I am curious though, heaps certainly must not have an absolute order since heaps are only partially ordered, so there must be multiple orders that all satisfy the heap ordering property, right? I guess even if it was fully ordered, though, non-determinism could still cause issues if the Less() function is not stable.)

[jhump]

range over newMap

🤦, yes, that's exactly what it is. Great observation! That's why on both failed runs it doesn't show up until later in the test, and it's always between "g" and "h" (two elements in the map, so some iterations they are inserted in one order, others the opposite order).