Before making progress here, we want to turn heuristics and searches into
factories (see issue559).

1. remove root task from the parse method of CostAdaptedTask (already removed
from ctor in issue776)
2. pass task from planner.cc through option parser to search engine ctor
3. use search task for checking preferred operator applicability (easy after
issue835)
4. replace global variable by local variable in planner.cc

added reference to issue559 and updated item 1 to reflect that it only handled
part of the problem.

I changed this to a meta issue to keep track of the necessary changes. I no
longer consider it part of issue509 because this is not about using the task
interface, it is about how to pass the root task (and its transformations) to
the components that need access to them.

Once issue776 is merged, CostAdaptedTask will still use g_root_task but the
usage will no longer be in the constructor but in the parse method of the task
transformation. Getting rid of this is the same problem as getting rid of
g_root_task in the constructor of the search classes (item 2). We currently
cannot replace these easily because our task transformations are not really
transformations, they are tasks themselves. 

The current assumption that the task of a heuristic or search engine is known
when it its constructed, is not compatible with general task transformations and
predefined objects. For example, consider a heuristic h with a task
transformation f_h that is nested in two heuristics. If the other heuristics use
transformations f_1 and f_2 then the inner heuristic would have to compute
values for both f_h(f_1(root)) and f_h(f2(root)). This is not possible with our
current model. 

We discussed this today and plan to move towards code where task transformations
are represented as functions on tasks (mapping tasks to other tasks) and where
we use factories to pass the relevant task to objects like heuristics when they
are used. Once this is done, we can pass g_root_task to SearchEngine::search
which will use the factories to generate the required objects for the given task.

Until then, the search engines remain fixed to g_root_task and the open points
in the summary of this issue will remain open. The use of g_root_task in the
remaining items represents using the task that will eventually be passed through
the factory interface.

The root task is currently used in four places outside of root_task.cc:

1. It is hard-coded as the parent task in CostAdaptedTask.
   We should use the task that comes from the parameter instead and fix the
   resulting problems in the landmark heuristics.
2. It is used in the initializer lists of search engines.
   We should promote it to a ctor parameter and pass the task through the option 
   parser and the parse method into the constructor.
3. The heuristic uses it in some debug-only code that checks that preferred
   operators are applicable in the search task.
   We should use the search task directly there.
4. The last occurrence is in planner.cc can easily be replaced by a local variable.

Some of these points already have related issues, I added them to the summary.

Now that g_root_task -s only used in a handful of places, we can try to get rid
of it and replace it by a local variable.