Evaluate correctness of map-matching algorithm

[aoles]

Changes to the code of map matching algorithm over the past few years might have introduced some subtle bugs to the original implementation. For example, consider the following two places.

1. openrouteservice/openrouteservice/src/main/java/org/heigit/ors/mapmatching/hmm/HiddenMarkovMapMatcher.java

   Lines 264 to 267 in 40753af

   	//TODO: the commented out code doesn't seem to be equivalent to the current implementation. Bug?
   	//Point zt = z[xi.measuredPointIndex]
   	//Point zt1 = z[xj.measuredPointIndex]
   	double dz = distances[xi.measuredPointIndex]; // distCalcEarth.calcDist(zt.lat, zt.lon, zt1.lat, zt1.lon)

   distances array contains precomputed distances between consecutive points which xi and xj not necessarily are.

2. openrouteservice/openrouteservice/src/main/java/org/heigit/ors/mapmatching/hmm/HiddenMarkovMapMatcher.java

   Lines 397 to 403 in 40753af

   	//TODO: all the bookkeeping around road segments seems obsolete to me as the matching appears to happen
   	// based on matched points rather than segments. In fact, the size of `roadSegments` array is used in loops
   	// iterating over `matchPoints` which looks like a potential bug to me.
   	int edgeId = EdgeIteratorStateHelper.getOriginalEdge(qr.getClosestEdge());
   	if (!roadSegments.contains(edgeId))
   	roadSegments.add(edgeId);
   	mp.segmentId = roadSegments.indexOf(edgeId);

ORS map matching is based on the idea presented in the paper Hidden Markov Map Matching Through Noise and Sparseness by Paul Newson and John Krumm. The description of the algorithm can be found here, see presentation slides.

[aoles]

There have been identified some serious issues with the implementation of the ORS map matcher. Therefore, rather than fixing it it the decision was to switch to using the more reliable GraphHopper map matching endpoint.