Option 2) reminds me of the old "evaluation context" idea of issue77, although
that was mainly intended to pass information *into* the evaluators rather than
*out of the* heuristics. Maybe the ideas can be usefully combined -- I'll look
into that in an experimental branch.

After having a deeper look at how the heuristic information is currently used:
the original idea for this issue won't work. It is currently not possible to
take the information about the evaluation results for the "current state" out of
the heuristic objects because this information is needed in essentially
unpredictable places within the open lists. There are two main ways of
addressing this:

1) keeping the information inside the heuristics and making it the heuristic's
responsibility to access them efficiently, with a nicer protocol/interface than
currently

2) using auxiliary objects that store evaluation information for a given state
and allow efficiently querying the heuristic value for a given heuristic and
making sure it is only evaluated once during one state evaluation

At the moment it looks like there isn't a solution for this that we are all
happy with, so I'll mark this "resolved" in the sense of "leave as is". This
doesn't mean that we think it should stay the way it currently is, but the
suggested implementation strategy won't work, and I don't think more general
structural changes would fit under this issue as we have currently defined it.

Another motivation for this is to simplify the heuristic interface in the sense
that you no longer have to remember to call evaluate() before get_heuristic() etc.

We plan to change the way heuristics are evaluated. Instead of calling
evaluate() and then asking for information (heuristic value, dead end detection,
preferred operators), the plan is to have one function that returns all required
information in one object (EvaluationResult). Optional parameters which default
to true specify which information is required.

Use cases:
In the sampling procedure of iPDB, we are interested in whether a state is a
dead end (but not its heuristic value or preferred operators). This can be
computed much faster than computing the full heuristic value.

In the landmark heuristic with the landmark synergy, computing preferred
operators can require additional overhead that can be avoided if they are not
needed.