Move curvature EncodedValue out of MotorcycleTagParser

[karussell]

I kept the meaning of the curvature value but instead of (beeline/edge_distance)² it is now only beeline/edge_distance as it did not make a big difference (sure, the small deviations from 1 will be "earlier snap to 0.95", but in practise this didn't matter in my simple tests and having a simpler formula was preferable).

If you want to use curvature to prefer curves then do not overdo it and something like this is sufficient:

{ "priority": [{
   "if": "curvature > 0.9",
   "multiply_by": "0.3"
}]}

Otherwise, without proper turn costs, you'll see things like:

I tried to calculate some kind of a max_curve value instead as the curvature was sometimes a bit too similar to 1 and used the maximum orientation change of the PointList like:

for (int i = 1; i < pointList.size(); i++) {
    double orientation = ANGLE_CALC.calcOrientation(pointList.getLat(i - 1), pointList.getLon(i - 1),
            pointList.getLat(i), pointList.getLon(i), false);
    if (i > 1) {
        orientation = ANGLE_CALC.alignOrientation(prevOrientation, orientation);
        maxCurve = Math.max(maxCurve, Math.abs(orientation - prevOrientation));
    }
    prevOrientation = orientation;
}
maxCurveEnc.setDecimal(false, edgeFlags, Math.max(maxCurveEnc.getMinStorableDecimal(), Math.min(maxCurveEnc.getMaxStorableDecimal(),
       Math.toDegrees(maxCurve))));

But at the end it did not properly show when a road was curvy (even sometimes not for serpentines). Probably because a curvy road in OSM is often mapped smooth leading to relative small orientation changes. Of course this could happen with the curvature too if multiple ways are created but often this is not the case and of course we would need another feature like "turning angle" to complement this. A good test route for this was here.

[easbar]

Nice! I did not look at the exact modeling of the curvature EV, but the code changes LGTM.