Merged and pushed.

OK, looks fine.

It seems like we currently only measure wall clock time for the preprocessor.
These tend to be better for larger tasks and worse for smaller tasks:

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue560_base_v1_preprocess_wall_clock_time.png

There is no difference in output files except in three trucks-strips problems
which is probably caused by finished/unfinished invariant analysis as we
discussed offline.

I think a blind search before/after experiment that looks at preprocessor
runtime would be good for this. It's easy to accidentally introduce copying by
forgetting a "&" in a loop, for example.

If I were working on this, I'd do a complete before/after translator +
preprocessor run and compare if the preprocessed results remain the same. With a
single core on a desktop PC (i.e., without the grid), this should take a few
hours at most, especially if you only run the translator once. (I've done this
frequently recently when working on translator bugs.)

Done: https://bitbucket.org/flogo/downward-issues/pull-request/1

Jendrik, could you have a look to make sure I didn't mess up a loop? Do we want
experiments for this?

Sounds good.

The preprocessors Makefile currently contains -Wno-sign-compare and 
-Wno-deprecated. When we switch to cmake (issue67) it will be easier if we can
use the same options for preprocessor and planner (also, it would generally be
better to not ignore the warnings).

I had a short glance at this and it looks like -Wno-deprecated can just be
removed and the only reasons for -Wno-sign-compare are a lot of for loops that
compare with something.size().

I suggest we switch these loops to range-based for-loops where possible and
store the size in an integer where not possible.