introduce alphanumeric signal group name

[namdre]

Idea 1

<param key="signalGroup:FZ21" value="1 2 3 4"/>
<param key="signalGroup:FZ22" value="5 6"/>
<param key="signalGroup:BL3" value="5"/>

Idea 2

<connection from="E1" to="E2" fromLane="0" toLane="0" signalGroup="FZ21 BL3"/>

Usage:

• annotation
• visualization in Tracker (show one tracker line per signal group and name it accordingly)
• optional visualization in sumo-gui (render names of 'green' signal groups)
• use by python tools
  • https://github.com/DLR-TS/sumo-ocit
  • maybe simplify inputs for https://sumo.dlr.de/docs/Tools/tls.html#tls_csv2sumopy
  • or https://sumo.dlr.de/docs/Tools/tls.html#tls_csvsignalgroupspy

[namdre]

this could be used to simplify ocit2sumo workflow At the moment, the tool requires hard-to-explain annotation of the ocit.xml file with sumo signal indices. Instead the signal group names could be put into the .net.xml or an tls.add.xml file and then read by ocit2sumo.

[namdre]

Reasons for not putting this in an optional connection attribute:

1. this carries some redundancy in case the network uses (numerical signal groups): each connection would need a signal group name attribute even though there are far fewer groups than connections.
2. it would have to be a list attribute since one connection can be associated with multiple signals (and thus signalGroupIDs)
3. in principle different programs could use different signal group names (i.e. to model different blinker configurations) and this would work just fine when the groups are part of a program definition

Reasons for using a connection attribute:

1. this makes the signal groups robust when adding/removing connections (which tends to reassign tls indices)
2. tls indices are generally hard to work with
3. modifying connection attributes has a better UI compared to editing parameters (i.e. changing many connections at once)
4. tls_csvSignalGroups.py also assigns signal groups via connections (or implicitly via incoming edges/lanes)