We removed the bucket open list in issue683, so I am closing this issue.

Once again, I give this up  for today because lab performs some magic that I did
not ask for and that makes it prohibitively expensive for me to analyze my
experiment data.

Perhaps it's good to try heuristics with different speeds and different amounts
of tie-breaking craziness. How about blind(), cg() and ff()?

I think we should simply run some experiments to compare the bucket vector
implementation to the one using maps. If it has no advantage, we should get rid
of it entirely, otherwise we should exit with EXIT_UNSUPPORTED.

Malte, any suggestions which heuristics  we should use?

Gabi, do I remember correctly that you looked at these open lists recently? Any
insights about what is used and what should be removed?

resolution:
 * get rid of the bucket-based open queue if it is not used
 * document that negative key values need to be supported

I don't think support for negative values is needed, but it'd at least be good
to catch that, at least with an assertion.

Independently from this, we should drop the bucket-based implementation if it
has no compelling advantages. Being able to remove code is always good. I guess
some experiments would be good though. The most critical algorithm/performance
measure combo should be the runtime score of blind search. If the bucket-based
implementation does not help there, I doubt it'll help anywhere.

Currently, the BucketOpenList does not support negative key values and can only
be used with evaluators that resolve to non-negative values. 

As far as I see this, it is unlikely that it needs to be used with negative
values, but then it should warn if somebody tries to use it like this.

Alternatively, we could think about removing the bucket-based open list from the
trunk, because the map implementation is not significantly worse in the case of
unit action costs and in general better in the presence of action costs.

The third possibility would be to implement the support, which should not be a
big deal, either.