Simplify gain evaluation when moving parts of routes in operators

[jcoupey]

Issue

Fixes #1266

Tasks

• Implement relevant high-level cost computation functions
• Assert that custom evaluation costs can be replaced by function calls
• Replace existing evaluation cost with high-level function calls
• Update CHANGELOG.md (remove if irrelevant)
• review

[jcoupey]

After some testing, it turns out that moving to the most simple interface has some drawbacks in term of efficiency: computing time increase ranging from 15 to 45% (at -x 5) depending on the benchmark class. :-/

For example the previous in_place_delta_cost evaluation is very straightforward and efficient because it relies on the fact that we're exactly swapping one job with another. Switching that to a generic "replace that range by that other range, but actually the ranges are just one job" adds quite some boilerplate to the code that is run in hot loops.

We'll probably have to figure out some compromise between code simplicity and efficiency.

[jcoupey]

After a couple optimization tricks, we're now back to acceptable time impact: below are the average computing time in ms on several benchmarks compared to parent master at 67eba4f. d1c596d is when the full logic is transferred to the most generic addition_cost_delta function. 138751f is the tip of the PR branch, after re-introducing some dedicated functions for some simpler evaluations appearing in hot parts of the code, and also making sure we get both "straight" and "reversed" cost delta at once when evaluating moving some edges.

Bench class		master	d1c596d		138751f
Academic	CVRP	2505	3070	22.55%	2464	-1.64%
	PDPTW	46	46	0.00%	44	-4.35%
	VRPTW	132	195	47.73%	161	21.97%
	MDVRP	305	418	37.05%	337	10.49%
	HVRP	547	670	22.49%	562	2.74%
Custom	CVRP	623	906	45.43%	566	-9.15%
	PDPTW	2163	2838	31.21%	2321	7.30%
	VRPTW	716	1041	45.39%	870	21.51%

Reintroducing a dedicated function is a trade-off as it means more stuff to modify for #1252, but worth it in term of efficiency.