Thanks for the review, Jendrik! I just merged the code.

I'm fine with the basic idea. From what you described about the experiments and
considering that this doesn't change code in the core, I'm fine with seeing this
merged without having looked at the code.

I had another look. I have no objections to merging this.

If anyone of you want to have another look or comment on the experiments, please
let me know. Otherwise I'll merge this issue next week.

Thanks for your input! I'm done with my changes now.

I left some comments on bitbucket.

Malte, would you like to look at the diff (i.e. should we keep this for the
queue) or can I go ahead if you agree that the experiments look good?

The merge-and-shrink heuristic now extracts the final merge-and-shrink
representation and the corresponding distances from the factored transition
system when the computation is done, and then updates the representation to
directly store the distances. This way, the factored transition system only has
to offer a method to transfer ownership over the final entry, but does not
impose users to store distances in the representation.

I ran an experiment, and the results are ok, but not overwhelming:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue682-v1-issue682-base-issue682-v1-compare.html

Memory (slightly) decreases as expected, runtime is not affected significantly,
and coverage is within +0/+1.

I created a pull request here:
https://bitbucket.org/SilvanS/fd-dev/pull-requests/23/issue682/diff

The diff consists of renaming the representation class and the change to FTS and
the heuristic described above, plus some small refactoring and polishing.

As discussed in today's Fast Downward meeting, we want to keep
FactoredTransitionSystem general and not enforce that distances are
automatically stored int the root representation in the end. We may offer this
optionally, as a postprocessing step of the merge-and-shrink heuristic which
would not affect the FatoredTransitionSystem class.

This is part of meta issue567.

This issue will address item 

M. heuristic representation:
  - The class that is currently called HeuristicRepresentation doesn't
  represent the heuristic. It represents the abstraction. Suggestion:
  rename it to MergeAndShrinkRepresentation, which is the name we use
  in our ICAPS 2015 paper.
  - We currently have a two-stage heuristic lookup process: map the
  concrete state to an abstract state, then map the abstract state to
  a cost value. The second step is unnecessary since we might as well
  write the cost value directly into the table of the MSR's root node
  (both costs and abstract states are represented by the same type).

of issue567. Furthermore, I'd like to simplify the way in which the
merge-and-shrink main loop in the end "finalizes" its computation depending on
whether the abstraction is already unsolvable in the initial state or not. In
particular, writing costs directly into the MergeAndShrinkRepresentation, we do
not need to keep the FactoredTransitionSystenm in the end, but only the
representation (because we do not need to keep the representation and distances
anymore).