Better costs modelling at vehicle level

[jcoupey]

Issue

This PR aims at improving the way costs can be fine-tuned at vehicle level, including:

• fixed costs (fixes Fixed cost for a vehicle #528);
• cost per time unit per vehicle (fixes Cost per hour in vehicle profile #732).

Tasks

• Parse fixed cost in input
• Parse time cost factor in input
• Update cost reporting in output
• Adjust OrOpt operator to account for fixed costs changes
• Adjust RouteExchange operator to account for fixed costs changes
• Adjust PdShift operator to account for fixed costs changes
• Adjust Relocate operator to account for fixed costs changes
• Adjust ReverseTwoOpt operator to account for fixed costs changes
• Tune vehicle ordering in heuristics
• Benchmark
• Update docs/API.md
• Update CHANGELOG.md
• review

[jcoupey]

Here is a quick summary of the results I'm getting with the state of this PR on the HVRP benchmarks I gathered.

x	Average gap (%)	Median gap (%)	Worst gap (%)	Average computing time (ms)
0	7.41	6.35	44.14	72
1	5.66	4.73	44.14	168
2	4.81	4.14	44.14	362
3	4.35	3.85	43.6	603
4	3.96	3.45	43.6	1095
5	3.74	3.32	43.6	1730

Comments:

1. The gaps are quite hard to get down, those results have involved quite a lot of testing and introducing a new operator. The HVRP is significantly harder than the CVRP since there is an additional affectation problem to decide which vehicles to use. I've tested many things around this in the scope of our solving framework but there is no simple rule that works across all instances to decide on vehicles to pick based on fixed/variable cost and capacities.
2. I feel this is good enough for now because:

• as usual the real-life instances are probably much simpler usually (especially with a more or less adjusted fleet, the hard part with the benchmarks being that they have an "open-bar" setup on a lot of different vehicle types);
• computing times are still quite low (this is not even a release build) which leaves us with some room for further improvements later on.