REL-1436, REL-615: QPT bug fixes caused by faulty comparison of Alloc objects.

A faulty comparison (based solely on compareTo of Interval) in Alloc objects caused a variety of problems when Alloc or Marker objects were stored in sets because Allocs that covered the same time interval were considered equal and therefore removed from the set. This fix addresses two issues:

1) After cutting and pasting observations from one variant into another one the corresponding problem markers were lost (unless one of the observations was moved around so that it covered a different time interval.
2) If two observations with the same duration were put on top of each other one of them vanished from the variant because it was  removed from the underlying AllocSet.

There are probably more elaborate/cleaner ways to fix this but I was trying to find a fix that is as local as possible in order to minimize the risk of unwanted side effects.

This is now consistent with equals whereas before it wasn't.  (I note that `Marker` is *not* consistent with equals -- though that isn't part of this PR.) The contained `obs` field is also `Comparable` so I suppose we could get a more natural ordering by also trying that first before resorting to the `hashCode` but maybe in practice all the `Alloc`s with the same interval are for the same `obs`?   I have two questions though:

* Shouldn't the `setupType` and `shutterTime` be included in `equals()` and `hashCode()`.  I realize that probably isn't part of the bug in question but it seems wrong not to add them.

* I see how the `AllocSet` puts `Alloc`s in a `TreeSet`.  This obviously makes two `Alloc`s covering the same interval but otherwise distinct remain in that set, which is where the bug fix comes in.  Are we confident nothing else depended upon the old behavior of filtering out multiple `Alloc`s for the same interval?