Graphhopper: turn_costs handling in /isochrone

[easbar]

Recently we fixed the handling of turn_costs for the /isochrone endpoint on the 1.0-pre32-fixes, but these changes also need to be ported to current master.

• [x] proper handling of turn costs parameter for /isochrone and /spt
• [x] The other thing we are missing is the turn_costs<->edge_based conversion we are already doing for /route (at least for GET requests, see #1966). The same holds for /spt as well! -> done here: 8a24e31eb772e5989c4e3eb1fc09068986a608a5

[easbar]

We should probably do this parameter handling in ProfileResolver (at least starting with #1958), then there should no longer be need to do this in every Resource.

[easbar]

So far we only support node-based for isochrones. So we either have to make sure there is a profile without turn costs or we make sure the isochrone algorithm (which is node-based) ignores turn costs or we use the __disable_turn_costs_for_lm_preparation flag in GraphHopper#createWeighting (and probably rename it back to __disable_turn_costs). See also #1965.

[easbar]

Assuming isochrone cannot be run edge-based (as is currently the case), whats better (or less ugly):

• it does not matter whether or not a profile has turn costs and the turn costs are ignored for /isochrone even when turn_costs: true is set in the profile

• /isochrone does not allow profiles with turn_costs: true, because its not implemented. So to make use of /isochrone we always have to add a profile with turn_costs: false and potentially we have to add a copy with turn_costs: false for every profile we want to use to make it also work for /isochrone.

If both options are too ugly we should consider implementing edge-based for isochrones...

I think I prefer the first option for now and its implemented in #1975