Rework solution space jump

[jcoupey]

Once we've reached a local minima, we try jumping around in the solution space by removing n jobs from each route, then re-inserting them heuristically, then rerunning a local search phase. Here n depends on the exploration level and current depth stage.

While the overall principle of ruining and re-creating a solution once in a while has proven its worth, the current implementation has major drawbacks.

1. n is between 1 and 5. This was deemed enough at the time of implementation while testing on Solomon 100-jobs instances, but does not make sense on much bigger instances. The number of removed tasks should probably be proportional to the instance size.
2. The current process removes exactly the same number of tasks in all routes. It would probably be much more efficient to remove "overall best candidates" (to be defined). This way some routes may stay virtually untouched while others could be mostly destroyed.
3. The current way the best candidates per route are found is somehow expensive, especially when applied several times in a row.

Those statements bring more questions than answers, but I really feel we could make a better use of the search depth if we improve the current logic.

[jcoupey]

This idea is complementary to #508.

[jcoupey]

I spent a lot of time testing several ruining schemes, to no avail so far. The ruining process relevance is very related to the recreation approach we use and currently the changes made for #1155 are taking over any attempt at changing the ruining part. In fact I've come to the conclusion that the new recreation process is much too greedy and changing it lost us the subtle search balance we previously had between exploration diversity and focus around good solutions.

More precisely: greedily (re)-inserting jobs while recreating does currently reach to much "wilder" solutions that are very different from the initial (pre-ruin) solutions. While this is good in term of search diversity, the impacts are huge: following local search steps are much longer because solutions are usually poorer after recreation and we loose some focus to find solutions "close" to the ones we ruin. As a result overall computing times are significantly higher (despite faster recreation) with globally decreasing solution quality.

I plan to revert the changes done for #1155 before getting back to see if we can improve ruining.