OK, changes are integrated now. This only leaves the dry-run thing, which I've
added as a comment to issue104. Marking this one as closed.

Will keep 3 in mind. Should be possible.

I'll make the parser case-insensitive for now.

I will leave 3 to Moritz, because he is the one currently working on the parser
code. I am fine with case insensitive options.

I took care of 1, 2 and 4.
I will leave 3 to Gabi, since I'm not entirely sure about what's going on there.
I've also updated the wiki, please have a look.

Regarding upper case - I think the code should be case insensitive, and the 
documentation should use upper case.

Some things I noticed in merging issue122.

1. I think the planner should complain with an error when using the nonsensical
LM option combination "optimal=true,admissible=false".

2. The usage string from planner.cc should include the "--landmark" option *OR*
if we don't want to maintain that, the usage string should go away altogether
and just point to the website. Which do we prefer?

3. When using an option string like
   ./downward --landmarks 'x=lmgraph_hm(m=2)' --search "astar(lmcount(x,
     invalid_option=true))" < output
the planner spends a lot of time computing the landmark graph and then complains
about the invalid option. Can we go through the complete command line in dry run
mode once before doing anything else?

4. I think the current names for some of the LM generation methods are too
technical/too much based on internal names. I would suggest that the RPG-based
methods use names following the AAAI 2008 paper (lm_rhw, lm_zg) and the hm-based
method is called lm_hm. I don't really know what the other two do, but I guess
lm_exhaust and lm_search makes sense.

BTW, should we make them upper-case? More generally, do you agree that the
options code should be case-insensitive? Then we could document things like
LM_RHW as upper-case, but internally both would be allowed.