Done and merged. Erez, please integrate with your repository ASAP since there
are major changes to the heuristics. I hope this doesn't introduce new bugs --
it's certainly critical code -- but I think we need these changes to properly
support action costs, so I don't think there's much we can do.

I changed four heuristics:
 * h^add
 * h^max
 * h^FF (normal version)
 * h^FF (FF/LAMA synergy version)

I did some basic performance tests. Unfortunately, in all cases the tie-breaking
changes (this even affects h^add if we use preferred operators); I think there
is no reason to assume it changes for the worse, but that makes performance
tests harder.

It looks like h^add and the synergy h^FF got a bit faster; h^max doesn't seem to
get worse at least. Plain h^FF may now be a bit slower, but that's because it is
now a proper FF(h_add) implementation rather than the weird thing it was before.
Hopefully that will improve accuracy on average, but that's impossible to predict.

Action cost support for h^add is done and pushed in the issue174 branch.

Performance looks OK. In some cases it is better than before, in others worse,
and altogether it's too noisy to be conclusive. Hard-to-predict cache-related
factors probably play a big role, and since these vary a lot from machine to
machine, I'll leave it at the preliminary benchmarking I've done on my local
machine, which looks good enough.

I haven't merged the branch into the default branch yet since h^max and h^FF may
be temporarily broken due to the changes to RelaxationHeuristic. From here it
should be very little work to finish those two heuristics, but I'll leave that
for tomorrow.

Note: must also work on the h^FF variant in the landmarks/exploration class,
which currently handles action costs, but only with a bucket-based
implementation, which is not adequate as h^add values grow large.

Implement proper action cost support for h^add, h^FF and h^max.

See also: issue173.