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.