Merged. Thanks, Emil!

Malte - Invited you to my public repository, let me know if I did things right and 
you can pull the changes. Erez gave very good instructions but I may have managed 
to do it wrong despite that.

Actions with empty preconditions weren't being correctly applied at the 
beginning of LM computation. It's five lines of code to fix, but I have no idea 
how to do a commit in mercurial or whether i have permissions to do that, can 
someone let me know?

Also I had to add a few #ifdef __APPLE__ type things to compile on OS X, let me 
know if you want those changes. They're in exact_timer.cc and in utilities.cc.

Emil has kindly agreed to look after this one.

No, and I'm not sure if he wants to support the code further, but we can
certainly ask him. Can one you send him an email? If he's willing to support the
code further, the best thing would be if he created an account on the tracker to
simplify future interactions.

Since this message is from the h^m landmarks code, I think it should be assigned 
to Emil (is he on the issue tracker?)

In solvable tasks from the Hydraulic Leaking domain from the ASP competition, A*
with the h_m landmarks prints a warning to the screen "Subset of goal not
reachable !!" and declares the initial state to be a dead end. Sample input is
attached. I've used this argument string:

--search "astar(lmcount(lm_hm(m=1),admissible=true),mpd=true)"

When using rhw landmarks, there is no warning message and the instance is solved.

The one issue is that the warning "subset not reachable" is wrong in this case;
the other issue is that if the warning was correct, one would expect the search
to abort straight away rather than trying to solve the instance. E.g. when using
the combination of rhw and hm landmarks we get the warning but yet the search
proceeds to work on the instance (actually solving it).