Add internal 2 opt

[jcoupey]

Issue

Fixes #706

Tasks

• Implement cvrp::IntraTwoOpt
• Implement vrptw::IntraTwoOpt
• Add move to current LS pattern
• Make sure we don't reverse full shipments along the way
• Use insertion rank bounds from Use insertion ranks bounds for LS operator pruning #696 for pruning
• Benchmark
• Update CHANGELOG.md
• review

[jcoupey]

So I ran a couple comparisons between current master and this PR. The new operator does change the search path when applied so sometimes also the final solution.

Quality difference

Here is the average gap to optimal solution on the usual CVRP/VRPTW instance sets in both situations.

Bench	x	master at ca37586	this PR at f341083
CVRP (A..X)	0	+2.67%	+2.65%
CVRP (A..X)	5	+1.32%	+1.30%
VRPTW (Solomon)	0	+4.54%	+4.30%
VRPTW (Solomon)	5	+1.83%	+1.63%

So on top of avoiding embarrassing crossings in the provided solutions, adding this operator does have a contribution on overall quality.

The impact on PDPTW and bigger VRPTW instances looks somehow similar, maybe with less overall impact as the problem size grow.

Timing difference

That's the nice part: there is virtually no difference in average computing times on those benchmarks, this PR being even sometimes slightly faster. I see two reasons for this:

• the new operator is relatively cheap compared to others involving more boilerplate;
• applying the new operator means making a bigger step in gain improvement which in turn fasten the convergence (number of applications for other operators is slightly reduced).