Merged and pushed. Thanks, Florian! I created issue637 for the refactoring work.

I didn't have too much time to look into this, but the code looks ok, and the
results are almost completely positive. I still think the design is too tightly
coupled and the classes AbstractSearch and AbstractState would need some
refactoring. But this is a general point that I already mentioned in issue600
and is unrelated to this issue. From my side, we could merge this and create a
follow up issue for refactoring.

I already ran some experiments and the results look quite good:

http://ai.cs.unibas.ch/_tmp_files/seipp/issue632-v1-issue632-base-issue632-v1-compare.html
http://ai.cs.unibas.ch/_tmp_files/seipp/issue632-v1-landmarks-goals-issue632-base-issue632-v1-compare.html

(In the second report the new version uses more memory, since it can produce bigger abstractions in the same 
amount of time.)

Yay, Florian agreed to have a look :)

I opened a pull request at https://bitbucket.org/jendrikseipp/downward/pull-requests/44 and 
will ask Florian if he can have a look.

Currently, the AbstractSearch class uses two unordered maps for mapping 
AbstractStates to g-values and incoming shortest path arcs. Updating these 
unordered maps takes a lot of time and we want to find better data structures 
for this information.

My current plan is to add the information to the AbstractStates themselves in a 
single struct. The struct should contain the g-value and the incoming arc. This 
allows us to query g-values and arcs efficiently given an abstract state.