Thanks everyone. I merged the code after making the remaining changes.

Done reviewing on bitbucket. The only point we were not so sure about were the
dump methods, as already discussed with Jendrik. Can be merged once this is
resolved.

I had a look and left a few comments.

I broadened the scope of this issue to cleaning up all of the code that remains
in globals.{h,cc}. Most of the remaining code simply should be moved somewhere
else and the one more complex issue (handling is_unit_cost) can be reviewed and
tested together with those code movements. If you disagree I'm happy to split
the issue into smaller parts.

The pull request is now up to date and ready for review again. You can see the
full diff here
 
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/45/issue793/diff
but looking at individual commits might be more helpful:
 
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/45/issue793/commits

Note to Florian: I discussed offline with Jendrik that the two of you should
discuss this offline (or online ;-)).

It's probably best to discuss this offline with Malte :-)

When I started this issue, I collected the functions in one place as you suggest
but I stopped half-way through. There were several things I didn't like about
this approach: 
* The code for printing a class is separated from the class itself, so when you
add stuff to the class, you have to remember to also add it to the print
function in a different file. 
* dump_task::dump_state_fdr(s) is less readable to me than s.dump_fdr() mostly
because of the explicit namespace.
* It is not clear which dump functions belong in this new file or where the
remaining dump functions should go. For example, what about CausalGraph::dump()?
 The causal graph is returned by a method in TaskProxy just like GoalsProxy, so
does its dump method belong in dump_task? If not, where should it go?

I'm still not completely opposed to the idea of using functions but maybe its
better to have them in task_proxy.{h,cc} next to the classes they print?

I think we're trying to use functions instead of methods if we don't need to 
access private members. Therefore, I think it would be better to collect "dump" 
functions for proxy classes in a new task_utils/dump_task.{h,cc} module (maybe 
using a better name).

The following pull request is against issue774 because it is easier to merge it
before we consider this issue.

https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/45

We already have some methods to produce debug output of objects (States, some
information of operators, a dump method for the global task, etc.). In this
issue I would like to try and collect them all in one place. This came up in
issue774 where the global dump method was one of the few things to remain in
globals.cc