Merged and pushed. Thanks Jendrik!

Florian addressed my comments. From my point of view this can be merged.

That makes sense. I have no further comments.

I think global objects are best avoided; they reduce flexibility. The
--internal-plan-file and --internal-previous-portfolio-plans options are obvious
hacks, too, and would more naturally be part of the search algorithm options in
the same way that the passed-in bounds are. One of the reasons they currently
aren't is that the option parser doesn't support string arguments.

If we ever later want to allow specifying multiple searches, it would make sense
for them to operate on different tasks and write to different sources. More
generally, I think the option syntax should eventually be unified further so
that we use the same sort of mechanism for everything. Currently we have a bit
of a mix between the component-based option parser and traditional --option
style options. I think it would make sense for the latter ones to eventually go
away, except perhaps for things like --help with are general conventions.

I left some minor comments. 

The current patch adds a plan manager to the search engine. This works since we 
currently only allow having a single search engine (which is sometimes an 
iterated search engine). I wonder whether we shouldn't have a single global plan 
manager. This would allow having multiple search engines later and is better 
aligned with the fact that we also only allow passing one value for --internal-
plan-file and --internal-previous-portfolio-plans. In addition, the PlanManager 
class would not need any "setter" methods, since we could construct the plan 
manager once all relevant attributes are known.

I'll have a look at the code.

Thanks! Can you find a reviewer? I don't see why experiments should be necessary.

https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/41

I created a pull request for this. Despite the large number of changed files,
this should be easy to review (most changes just remove unnecessary includes).

Do we need experiments for this? I tried around locally with different ways of
passing the parameters: using aliases, satisficing/optimal search, calling the
binary directly with the internal parameters, etc. All my tests were successful.

g_plan_filename, g_num_previously_generated_plans, and
g_is_part_of_anytime_portfolio can be collected in a class that handles the
creation and storage of plans.