Closing this one. A basic implementation of this now exists (recently
implemented by Jendrik), and I think it should count as good enough until
someone uses it and complains that they need something better. :-)

I'm skeptical for a bunch of reasons.

1) If we implement this via forking and killing, I'm not sure if there's much
benefit over how we do things currently. We can save the parsing cost, but that
is usually not very high.

2) On the other hand, if we want to do all of this in-process, we need to add
"break if timeout exceeded" tests in all sorts of locations that can be
time-critical, such as landmark generation and heuristic generation, which means
that we must be much better prepared for aborting whatever we're doing in all
kinds of places.

3) Part of the reason why we currently handle portfolio runs externally is to
get a clean memory situation. There are quite a few places where memory is not
properly recovered at the moment. Even if were returned properly, we might still
have to deal with fragmentation issues if we didn't start from a clean slate.

4) Even if this were fixed, we'd need to support things we currently don't
support, such as "Build a M&S heuristic of type 1 now, then search with it,
*then* build a M&S heuristic of type 2, then search with that."

5) We'd need to be able to recover from out-of-memory situations, which is
generally quite tricky.

Having said all that, I'm not against this in principle. One way to proceed
would be to add an experimental implementation of this and perform some
experiments comparing its behaviour against how we currently handle portfolios.

Jordan asked about adding a timeout for individual searches, so that we can 
support portfolios "natively" rather than through an outside script.
He said he already implemented a timer in the search engine, and it worked 
pretty well - should be easy enough to make this a parameter, and return an 
appropriate 
TIME_OUT value from the search.
Any thoughts?