Decide if we want a custom task-independent component to reduce the nesting level. If so, open an issue and link it here.
* SubtaskGenerator
* LandmarkFactory
* LabelReduction
* MergeScoringFunction
* MergeSelector
* MergeStrategy
* MergeTree
* ShrinkStrategy
* OpenList
* ConstraintGenerator
* PatternCollectionGenerator
* PruningMethod
* SearchAlgorithm
* Potential Functions (they already have specialized components but we could re-evaluate the design and consider something more along the lines of PDBs where the pattern generation methods are their own components)

added a point to the summary about potential heuristics

Issue559 introduces task-specific components but so far only wraps our existing classes in a templated class that stores arguments and later passes them on to the existing class when a task is bound. Many of the existing classes are already factories that essentially perform the same functionality (storing arguments, waiting for a task and then constructing a task-specific object). This leads to factory-factory pattern that we want to reduce by one level in this issue. 

For example, with the change in issue559, LandmarkFactory is a task-specific component which is wrapped in a AutoTaskIndependentComponent. When bound to a task, the auto-component creates the LandmarkFactory for this task, which later gets another task in compute_landmark_graph(task) and creates a LandmarkGraph for it.
After this issue, we would like LandmarkGraph to be a task-specific component, and LandmarkFactory to be a task-independent component with the functionality that currently lives in compute_landmark_graph(task) moved to bind_task(task).

This affects possibly all our component types (listed in the summary). We can make a different choice for each one and handle each one in a separate issue to have smaller diffs and easier reviews.