Overhaul heuristic of calculating edge travel speed

[rabidllama]

The code that attempts to take into account acceleration has issues (such as short segments) which sometimes sends routes off of a more logical path.

The code needs to either be reworked, or a different method implemented that would reduce travel speeds to a more realistic value than the default of assuming that the vehicle is immediately travelling at maximum possible speed as soon as it enters an edge.

Possible alternatives include:

• Using traffic lights to reduce speed
• Identifying areas where speed is normally reduced (e.g. urban areas) and update speeds on the edges accordingly
• Determining complexity of the osm way (curviness, number of junctions, lanes, length etc.) and using that to influence the speed of the edges that make up that way

[aoles]

Cross referencing related issues:

• Example where acceleration fails https://github.com/GIScience/openrouteservice/issues/339
• An attempt to take traffic lights and pedestrian crossings into account https://github.com/GIScience/openrouteservice/issues/674