Different rounding in coordinate transformations in osmium wrt to osrm

[oxidase]

Some tests expectation are ad hoc and have significant differences if input data is slightly translated, for example

    Scenario: Car - Check roundoff errors
        Then routability should be

            | highway | maxspeed | forw    | backw   |
            | primary |          | 52 km/h | 52 km/h |
            | primary | 60       | 47 km/h | 47 km/h  |
            | primary | 60       | 47 km/h | 47 km/h  |

fails in last row. The difference is due to rounding up in osmium at https://github.com/Project-OSRM/osrm-backend/blob/master/third_party/libosmium/include/osmium/osm/location.hpp#L183
but osrm uses truncated coordinates at https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/coordinate.hpp#L77.

In the above test

OSM/request	osmium reads	osmium rounds to	node lon	phantom input
1.926039974358575	192603997	19260400	19260400	1926039

so for phantom input 1926039 weight is 1499 and speed is 3.61999.8/149.9=48.0272181454 -> 48,
but for phantom input 1926040 weight is 1500 and speed is 3.61999.8/150=47.9952 -> 47
so initial relative error of 2e-7 propagates to 1/48 in the result speed.

Related issue #3354

[TheMarex]

Good find. We should probably use std::round here.

[TheMarex]

To fully fix these incompatibilities we need to switch from 1e6 to 1e7 coordinate precision. Since we expose the Coordinate objects to our users, that could be a breaking change, hence the 6.0 milestone.