Use insertion ranks bounds for LS operator pruning

[jcoupey]

Issue

Fixes #583

Tasks

• Store insertion rank bounds based on earliest/latest time for all jobs/routes
• Store weak insertion rank bounds based on TW for all jobs/routes
• Update relevant insertion ranks upon route changes
• Prune MixedExchange moves
• Prune CrossExchange moves
• Prune TwoOpt moves
• Prune ReverseTwoOpt moves
• Prune IntraRelocate moves
• Prune IntraOrOpt moves
• Prune IntraExchange moves
• Prune IntraCrossExchange moves
• Prune IntraMixedExchange moves
• Benchmark reduction in number of operator lookups
• Benchmark computing time reduction
• Update CHANGELOG.md
• review

[jcoupey]

Here are some comparisons on the usual VRPTW benchmark classes using -x 5 where results are nearly always the same in quality (a very small number of solutions have changed due to different search paths after fixing #682 along the way).

Average computing times

Computed for all instances in each benchmark class.

Bench	aa3a1ee	fe87ad8	delta (%)
Solomon	751	385	-48.7
Homberger 200	4094	1865	-54.4
Homberger 400	20873	9526	-54.4
Homberger 600	52193	23961	-54.1

So it's a steady 2x speedup! 🎉 Of course we're talking about instances where the TW are rather tight and constraining so the pruning approach does make a bigger difference.

LS operators lookups

Here is the total number of LS operators lookups across all benchmark instances.

Bench	aa3a1ee	fe87ad8	delta (%)
Solomon	2362150254	938754682	-60.3
Homberger 200	14479752836	5258489935	-63.7
Homberger 400	76064030714	25687922018	-66.2
Homberger 600	155454871416	60966284162	-60.8

The total reduction shadows differences related to TW tightness in the instances. For example the reduction in number of applied operator ranges from -22.9% to -86.0% across all Solomon instances.