Part of issue509

Merged, thanks! The buildbot is happy as well.

Looks good! I only left one small comment on bitbucket. Experiments don't look
too bad, either. Ready to merge.

As usual the satisficing results are much more noisy (noise goes up to +-50%).
Overall, it still seems fine to me. The coverage doesn't change (except for
one task with EHC) and I don't see a a clear trend for larger runtimes.

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-v1-sat-issue726-base-issue726-v1-compare.html
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-ehc_ff-search_time-base-v1.png
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-lama-first-search_time-base-v1.png

I ran blind search and LM-cut and both show some overhead. As expected, the
overhead is smaller for LM-cut (~3%) than for blind search (~5%).

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-v1-opt-issue726-base-issue726-v1-compare.html
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-blind-search_time-base-v1.png
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue726-lmcut-search_time-base-v1.png

Experiments for satisficing configurations are still running.

The code looks good to me.

I created a pull request for this on bitbucket:
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/36

There will probably be some overhead, I will run experiments to see how bad it is.

As a step on the way to make the search independent of g_operators, I would like
to change the interface of StateRegistry::get_successor_state from
GlobalOperator to OperatorProxy. I don't want to completely change the successor
generator to the new interface or change the responsibilities and control flow
of it (yet).