We discussed this in a meeting and found that we are fine with the current 
behaviour of lm_merged().

Another thing we should keep track of is to only add the relevant options to each 
landmark generator (see original discussion in issue563).

Good point. I've opened a new issue, issue257

> This is probably because some orderings are lost during merging.
> We need to think about this when we're working on this.

This point should be unrelated to the question whether the merging is done
on-the-fly or in a separate step. The sequence of insertions to the final merged
landmark graph is the same in both cases.

If there are no bugs, I expect that the loss in precision is due to the fact
that our implementation always drops a disjunctive landmark "A or B" when "A" is
also present, which can be suboptimal if "A or B" has orderings that "A" does
not have.

One example of why we need this: In depots03, using the merged graph (with the 
old logic) of RHW and lm_hm(m=1) leads to more expanded states than just with the 
RHW graph, when using optimal cost partitioning.
This is probably because some orderings are lost during merging.
We need to think about this when we're working on this.

Instead of having landmark factories *generate* landmark graphs, have them 
*modify* landmark graphs.
So their signature would be:
bool LandmarkFactory::discover(LandmarkGraph &lm_graph)

and they would
1. Utilize the information already present in the landmarks graph (for example,
backchain from existing landmarks rather than just goals).

2. Add landmarks/orderings to the given graph

This would allow us to create a landmarks graph that is the combination of
several landmark generation methods.

I suggest the method return whether it modified the graph or not, which would
allow us to iteratively combine landmark generation methods until we reach a
fixpoint.