Merged and pushed.

Yes, looks good! :-)

Since this was not assigned, I assumed you didn't start yet and grabbed it. I
created a pull request for it on my bitbucket account:
https://bitbucket.org/flogo/downward-issues/pull-requests/3/issue119/diff

The code also removes the DEACTIVATED option (it was only used for the learning
code, which is now removed, and the name was misleading). I also used the
DEPENDENCY_ONLY option for the LP solver.

Should I merge?

Sounds good! Instead of "HIDDEN", I'd prefer a keyword that focuses less on how
this is presented in ccmake and more on the code semantics, like "ABSTRACT" (in
the same sense that abstract base classes in C++, Java or Python cannot be
directly instantiated).

Another option that needs less explanation: "DEPENDENCY_ONLY". But all that is
bike-shedding, of course.

Hiding a plugin should be possible in the macro fast_downward_plugin in
cmake_plugins/FastDownwardMacros.cmake.

Together with the parameter DEACTIVATED, we could define the parameter HIDDEN:
    set(_OPTIONS HIDDEN DEACTIVATED)
We could also replace DEACTIVATED, because it is not used anymore.

Then, after parsing the parameters and defining the option, the following lines
should hide the option:
    if(_PLUGIN_HIDDEN)
        mark_as_advanced(PLUGIN_${_PLUGIN_NAME}_ENABLED)
    endif()

When you define the plugin in src/search/DownwardFiles.cmake just add HIDDEN
after the list of sources.

A short local test seemed to work, but I didn't test it thoroughly.

Hi Florian, I added you to this old issue as our resident plug-in expert. :-)

Suggestion:
1. We add a plug-in and namespaces for each relaxation heuristic and a plug-in
for the base.
2. We add the necessary dependencies.
3. Add a mechanism that allows us conveniently making the base plug-in invisible
in ccmake.

I can take care of 1. and 2., but would need your help with 3.

Various relaxation heuristics (additive, max, ff) have relaxation_heuristic.h as
a common dependency. For the plug-in mechanism, this means that we need
relaxation_heuristic.h iff we use any of these three heuristics. For now, this
issue is solved by simply having relaxation_heuristic.h *always* available
(i.e., it is considered part of the planner core), but we might want to switch
to a better solution later.

We might want to wait with such better solutions until we switch to a better
build system (like cmake) which might offer good solutions for this issue out of
the box.