Add flexibility for job time windows handling

[jcoupey]

Handling time windows for jobs works by storing additional data along routes, such as earliest and latest possible arrival dates at each step. Those are used to decide whenever a possible route change is feasible wrt timing constraints, and are updated each time a route is changed.

Currently, for a given job we pick the first compatible time window based on the earliest arrival candidate, then use it to update the new job earliest date and it's latest date. This is actually way too restrictive as we could avoid choosing the time window altogether and define a potentially looser latest date by picking another time window down the line.

As a result, in a situation with many multiple time windows, we're currently setting aside doable options that we consider as invalid due to the time window choice.

Consider for example jobs A and B whose respective time_windows arrays are: [[8h, 12h], [14h, 16h]] and [[14h, 16h]]. If the heuristic process starts by adding A to an empty route, then the matching earliest date will be earliest_A = 8h (or a bit more depending on travel time from the start) and because we picked the morning time window, it's latest date will be latest_A = 12h (or a bit less depending on travel time to the end). Then A -> B is fine, but B -> A is wrongly considered invalid because the new earliest arrival at A after B is necessarily after current latest_A. We should allow picking different time windows for earliest and latest date, in which case latest_A would be 16h in the first place and B -> A would be valid.

As far as I can tell, there would be no drawback with this change (except a bit more fiddling to search the relevant time window for both values). No change in validity checks, no need to store job time window any more, it would just be decided upon route formatting when we truly set arrival times.