Extend REST API response, improve heuristics, append new GeoJSON layers to the UI spatial map

[LdDl]

1. Added parser for edge_id column in CSV
2. In the UI example you can see new geospatial objects:

• Green dots - for the picked vertex of the matched edge for GPS measurement
• Yellow dots - for the projection of GPS measurement to the matched edge
• Magenta line - for the matched edge

3. Removed obsolete and redundant code for experimental Softmax
4. Updated go.mod to use v1.0.1 for Viterbi algorithm
5. Added to REST API map matcher response additional fields for the GPS measurements (a.k.a. observations):

• Matched edge identifier
• Matched edge GeoJSON feature identifier
• Picked vertex GeoJSON feature for matched edge
• Projection point onto the matched edge (GeoJSON feature)
• Observation index (to match request and response data)

6. Added debug verbose mode for Viterbi Algorithm. Could be helpful to test pure Viterbi algorithm
7. Added to REST API isochrones response additional field: vertex identifier
8. Added to REST API shortest path response additional fields:

• Matched edge identifier
• Matched edge travel cost (a.k.a. weight)

9. Now RoadPosition (candidate for matching) split GraphVertex to the two fields:

• PickedGraphVertex - vertex which would be used as matched vertex in the final response
• RoutingGraphVertex - vertex which would be used for building routing paths between candidates layers

10. Since I've introduced distinction between PickedGraphVertex and RoutingGraphVertex I can now achieve better results in map matching:

• Very first candidate layers should have edges' targets as the sources for building shortest paths. All other candidate layers should have edges' sources (!!!) as the targets for build shortest paths.
• After we build shortest paths between very first and second layer (edgeX.source -> edgeY.source) we should change targets for building shortest paths in other candidate layers pairs (so next pairs will be: edgeY.target -> edgeZ.source and then edgeZ.target -> edgeK.source and so on)
• It gives us a better handling for cases when a single vertex is indecent to multiple edges (which could lead to mismatch between shortest path edges and actually matched edge for the given candidate)
• The picture before and after this changes: Before (blue - road network, red - matched edges, green - restored path):

After:

Problematic place: two edges (source-2133|target-2134 and source-2133|target-4014) shares same source ID 2133. Image is below:

11. Modified map matcher response (+ and updated UI example):

12. Modified shortest path API: Aware: this is not exactly shortest path for know graph vertices but rather for matched vertices

Still W.I.P.

• Need to finish the code for cutting very first and and very last edge and append them to the full GeoJSON feature path
• Adjust failing test (with manual check if everything goes fine)