Additional CH config leads to error about map-matching

[easbar]

I had a look a this. There seem to be multiple things involved.

1. When we request with vehicle=car this means the ProfileResolver is used in MapMatchingResource to find a matching profile. If there are CH preparations it tries to find a CH profile and finds profile=car, because this is the only profile for CH. If there is no CH profile it tries to find an LM preparation and finds both profile=car_no_tc and profile=car, but in this case takes profile=car_no_tc, because it favors the profile with turn costs if both are available.

2. MapMatching does not really depend on the CH preparations. It only checks for the ch/lm.disable flags and if they are both false and there are some LM preparations it tries to find landmarks for the given profile. So if CH is disabled MapMatching uses the LM preparation for the car profile and everything is fine, but if we enable CH for car_no_tc it tries to find an LM preparation for profile=car_no_tc.

3. In MapMatching we are missing the implementation of the cross-query feature so far which means we cannot find landmarks for profile=car_no_tc.

So the first thing we need to fix is implementing the cross-query feature. This should fix this issue. However, its still ugly that ProfileResolver considers CH profiles and MapMatching does not. The problem here is that we are injecting a global instance of ProfileResolver in MapMatchingResource, but we need a slightly different resolver for map-matching.

[easbar]

And there is another problem: We cannot request with profile=car_no_tc either, because MapMatchingResource always uses ProfileResolver instead of skipping it when the profile parameter is used explicitly.