Improves lane handling for subsequent going straight, resolves #2625

Before we only worked on subsequent quick turns, as in:
`right, right` keeps the user on the rightmost lanes.

This changeset modifies the logic to work on any subsequent steps
that are "quick" and have lane information we can constrain later.

Because we do not have a from-lane => to-lanes mapping we take the
lanes left and right of the turn lanes into account when heuristically
assigning the leftmost / rightmost lanes.

There are some edge cases where this still does not give us the optimal
solution but it gets close to what is actually possible at the moment
without having a lane mapping in post-processing.

References:
- https://github.com/Project-OSRM/osrm-backend/issues/2625

fix rebase

include/engine/guidance/post_processing.hpp

@@ -15,7 +15,6 @@ namespace engine
 {
 namespace guidance
 {
-
 // passed as none-reference to modify in-place and move out again
 OSRM_ATTR_WARN_UNUSED
 std::vector<RouteStep> postProcess(std::vector<RouteStep> steps);
@@ -28,6 +27,14 @@ std::vector<RouteStep> postProcess(std::vector<RouteStep> steps);
 OSRM_ATTR_WARN_UNUSED
 std::vector<RouteStep> collapseTurns(std::vector<RouteStep> steps);
 
+// A check whether two instructions can be treated as one. This is only the case for very short
+// maneuvers that can, in some form, be seen as one. Lookahead of one step.
+bool collapsable(const RouteStep &step, const RouteStep &next);
+
+// Elongate a step by another. the data is added either at the front, or the back
+OSRM_ATTR_WARN_UNUSED
+RouteStep elongate(RouteStep step, const RouteStep &by_step);
+
 // trim initial/final segment of very short length.
 // This function uses in/out parameter passing to modify both steps and geometry in place.
 // We use this method since both steps and geometry are closely coupled logically but