feat: centerline ordering

The MR goal is to handle a different centerline points ordering. Situation right now is to have the centerlines always ordered coherently with the driving direction, while in osi standard can be ordered in both ways (see https://opensimulationinterface.github.io/osi-antora-generator/asamosi/V3.5.0/gen/structosi3_1_1Lane_1_1Classification.html#aefbd7976958f298e74e62ed43895562f). The consequent change will impact mainly the following modules:

• Core/Environment/TrafficSwarm/Internal/spawn_position_finder.cpp: since the centerline is used to spawn positions in front/behind host.
• Core/Environment/Map/LaneLocationProvider/lane_location.cpp: direction of polyline adjusted to give effective driving direction and lane_normal calculation too (different centerline_is_driving_direction would result in different right and left boundaries given OSI standard https://opensimulationinterface.github.io/osi-antora-generator/asamosi/V3.5.0/gen/structosi3_1_1Lane_1_1Classification.html#a27cc65913fe78232e6006222612a509e)
• Core/Environment/Map/Geometry/project_query_point_on_polyline.cpp: since now we are working with polyline wich are not always oriented in driving direction, we should now take it into account and traverse the polyline in the right way.
• Core/Environment/LaneFollowing/line_follow_data_from_path.cpp: to get the LaneFollowData still with point in driving direction we need to reverse the centerline and cut it in right way to cope with that.
• Core/Environment/LaneFollowing/line_follow_data_from_lanes.cpp: same as above: we want LaneFollowData points in driving direction, so we need to do necessary centerline manipulation when it is not in driving_direction.

For test purposes it was also needed to modify all the MapCatalogue, since we enabled the possibility to have different centerline ordering for each different lane group. This will enable to have a comprehensive and flexible catalogue which will have the same maps (in driving direction meaning, and not just physical for what concerns points of centerlines, boundaries) encoded in different ways (centerline_is_driving_direction). As already said, to be OSI compliant, if we reverse centerlines, we need than to reverse also boundaries and switch the reference of left and rigth since it's dependent on the polyline direction. All the MapCatalogue functions names changes are due to the fact that we want to specify that cardinal directions (Easting, Northing, ...) are concerning to just the driving direction and not also the ordering of points (e.g. all that contained EastingLane will change to EastingDrivingLane).

Pipeline: https://ci.eclipse.org/openpass/job/GtGenCore/view/change-requests/job/MR-165/