Merged and pushed.

I think they haven't since they asked me to do it :)

That sounds like a good idea to me, although we could also add a limit on the 
number of expanded/generated/evaluated states as well.

However, check with Jorg and the folks from UBC, since they already implemented 
probing runs in FD for their paper on features of planning instances.

We discussed getting rid of step() at some point because it's a relic of the
ancient cooperative scheduling mechanism from Fast Downward 2004. But I guess we
can worry about this once we cross this bridge.

(Personally, I would find limiting the number of expansions or evaluations much
more useful than limiting time, but then I have other use cases in mind.)

I think search timeouts would be useful for probing runs that report statistics after 
a specified timeout. Maybe they are useful for other things as well. For example they 
could be a first step towards allowing to pass multiple "--search" commands on the 
commandline each with a timeout (obviously this would require huge amounts of other 
code changes first).

I created this issue to allow discussion of whether we want this in Fast Downward and 
how it should best be implemented.

My implementation idea would be to add a "max_time" parameter to SearchEngine and 
check the already existing actual-search-time timer against it after each call to 
step() in SearchEngine::search().