Is there a reason for `SegmentHistory` to internally use a `Vec` vs `BTreeMap`?

[Daniel Larson]

SegmentHistory uses a Vec<(i32, Time)> internally while essentially mandating the interface and structure of a BTreeMap<i32, Time>.

Using a BTreeMap instead would theoretically improve insertion/removal costs to be logarithmic rather than linear, and it would statically guarantee that the list was sorted. It would also prevent mutating the keys when using iter_mut(), rather than only having a warning. (Given the way run data is structured, allowing this currently is probably not a great idea, and I think would virtually always constitute an error, as opposed to removing and inserting with the changed key.)

It would mean that the collection would no longer be contiguous in memory, but unless that severely impacts performance, I propose changing it to use BTreeMap instead of a Vec of tuples. This should be able to be done without changing the public interface, since the internal type is not publicly exposed. I'm willing to submit a pull request.

Edit: After looking into some of the function signatures, true safety for iter_mut would likely require a "breaking" change (the Item would be (&i32, &mut Time) instead of (&mut i32, &mut Time)), but it's only used in one place in the rest of the library, and it's unlikely to be used often in userland code, and will coerce just fine if it's not mutated (like in the core library) so I think it's still worth doing eventually.