these cases are not covered by the splitting algorithm at the moment:
* typicall, only a part of the roundabout should be part of the resulting route
* when multiple routes meet at a roundabout coming from different angles, the roundabout must be split at any of those entry/exit point simutaneously, such that all routes remain correct
as a workaround, a mapper can remove the route relation(s) from the roundabout, split it accordingly and then re-add the respective parts to the relation(s) again.
instead of fully re-sorting the whole relation every time a member is split, perform a local operation: This works under the assumption that the relation is already sorted properly. The new way is inserted into the relation before or after the existing member, depending on how the old/new way connect to their neighboring members.
for cases where two ways form a loop, a additional look-ahead is implemented to disambiguate the order
as it silently strips non-numeric suffixes (e.g. a value of "123 foo" is transformed into a numeric value of 123 by `parseFloat`, which is typically not what we desire)
Add endpoint to actionSplit to get the created ways after running the action
Change "Use bridge" or "tunnel" fix labels to "Add a bridge" or "tunnel"
Add layer tags on structure feature when adding a bridge or tunnel via a fix
Select all components of the split way when adding a bridge or tunnel via a fix
Don't recommend adding a bridge to a waterway
Don't show "change layers" fixes along with "add structure" fixes
Don't split or change the tags of coincident ways when adding a bridge or tunnel
Return old_multipolygon validation issues for the relations as well as the outer ways
Remove console logging
Don't run missing_tag validation for relations with old_multipolygon issues
