Remove lanes

[tthunig]

As discussed in the code sprint, we want to enable turn restrictions on the link level. With this we don't need the extra lane format in MATSim anymore: We can instead have multiple parallel links if we want to model separate waiting queues for different turn directions or traffic signals.

As far as we see, this only affects

1. visualization (in current Via links would be placed on top of each other; but current Via was also not able to visualize lanes) and
2. the insertion of agents into traffic from their activities, i.e. the choice of the appropriate link to enter the traffic (which is currently done at the first, common part of the link in case lanes are used).

Both issues could be managed by providing an alignment attribute on the link level (as before on the lane level) which determines the order of parallel links (see also the detailed proposal below).

Note, that signals in MATSim already work without lanes, as they only control outflow of queues (QueueWithBuffer). OTFVis is also already able to visualize traffic signals on links (and lanes).

Background:
MATSim's QSim is quite complex. For the link/queue representation for example we have AbstractQLink, QLinkImpl, QLinkLanesImpl and QueueWithBuffer which all depend on each other. If we are able to remove lanes, we could further simplify the remaining structure and make it easier to maintain/extend/replace functionality.

The picture shows different possible link/lane representations. Format 0 corresponds to the standard MATSim case without lanes, format 1 corresponds to the current MATSim setup with lanes, format 2 corresponds to a similar queue behavior as format 1 but without lanes (as soon as turn restrictions are allowed on the link level) and format 3 is a simplified version of format 2 with less accuracy in terms of spillback behavior.
As both, format 2 and 3, would be possible with the new turn-specific links, we can basically leave it to the user which one is chosen. For conversion, I suggest to go for format 2 (see proposal below).

Proposal:

• Enable turn restrictions on the link level
• Add alignment information on the link level (to define the order of parallel links; as before on the lane level).
  Example: An alignment 0 means the link goes straight, a negative alignment means it is/turns left (the more negative, the further), a positive alignment means it is/turns right (the more positive, the further). I.e. a three-lane link with one left-turning, one straight-going, and one right-turning lane could be modeled by three links with alignment -1, 0, 1.
• Provide a converter for old MATSim scenarios (network, lane, signal files, plans...) to format 2 or 3. I suggest format 2, because it contains exactly the same information as the current lane data in MATSim. Format 3 would result in a simpler graph, though, and might cause lower run times etc. but less accuracy. To keep it simple, we start with providing a converter for the simple case where only one intermediate node/branching point exists per link.
• Test performance compared to the current approach with lanes, e.g. with the Cottbus scenario.
• Remove lanes, i.e. remove all corresponding classes (including LanesToLinkAssignment, QLinkLanesImpl...), remove support of lanes in signals (e.g. lanes and turningMoveRestrictions in SignalData), remove LinkToLinkTravelTimes, adapt lane/signal visualization with OTFVis, adapt the lane example/add a new one...
• (?) Change the selection of the nearest link for activity locations to be dependent on the alignment attribute. In a tie, select the link with the highest alignment (furthest right) or select only links with no alignment/ neutral alignment (0)/ no turn-restrictions
• (?) Make Via use the alignment information to show parallel links next to each other