Adds an approximate timeout to coordgen

[d-b-w]

The timeout governs the "degree of freedom" optimization step (CoordgenMinimizer::runSearch()). For slow molecules, this step takes the bulk of the time in sketcherMinimizer::runGenerateCoordinates() calls.

However, there may be more than one call to runSearch()- it's done for each macrocycle and then again to combine the macrocycles. That being said, most slow molecules that I've seen do 1-2 slow runSearch() calls, not so many.

Here's a typical minimization for a slow molecule (that actually did three runSearch() calls).

The first two minimization cycles are for the macrocyle fragments, the last one is to combine those two. For this molecule, I didn't see an interesting difference in the final coordinates for a timeout of 0.05s (50milliseconds).

Use like:

sketcherMinimizer minimizer;
minimizer.initialize(mol);
minimizer.setApproximateTimeout(static_cast<std::chrono::milliseconds>(100));
minimizer.runGenerateCoordinates();

[ricrogz]

This makes sense to me as long as we document it very clearly that the timeout is not absolute, and that the real duration of the process depends on how many fragments need to be minimized -- which is something not really intuitive for the user. I think this should not only be documented in CoordgenFragmentBuilder.h, but also in sketcherMinimizer.h, which seems the initial entry point for setApproximateTimeout()

[d-b-w]

We're not going to do this just yet.