Rewrite tracking of OSM data across clipping

The previous approach put coordinate pointers into the point structures of
the clipper lib. This worked in most cases, but as there are no guarantees
on point references remaining valid, the clipper lib ended up swapping
values of points in some cases, breaking our coordinate references and
subsequently losing the attached OSM data. While this is usually not a
problem for a random node, it could also happen on the closing node of a
polygon, causing it to no longer be closed and confusing the hell out of
the geometry reassembly code.

The new approach tracks this outside of the clipper lib with a map on the
integer coordinates (and thus avoiding floating point number comparison
issues). This also allows us to roll back a bunch of Marble-specific
changes to the clipper code.