Meter distance computation in Web Mercator

[patrickbr]

The exact meter distance computation has several problems when done in WGS84 space. Most critically, if WGS84 is used directly as a map projection (plate caréé), the distance distortion is not uniform in x and y direction, but only distorted in x direction. This breaks a few assumptions in the search padding function. It would be possible to fix that, but that would add some code duplication. I tried that and it worked correctly, but because several speed-up heuristics are tailored to the web merc space, the direct computation on WGS84 was up to a factor of 4 slower. We also dont really need it, as all call sites of the old meter distance calculation already use web mercator projected geometries.

So this PR replaces all withinMeterDist and meterDist functions with webMercWithinMeterDist and webMercMeterDist functions which work exactly the same. The is also a preparation for updating the meter distance computation in QLever, which should be a simple update of libspatialjoin with this PR, requiring no changes in the QLever codebase. As discussed with @ullingerc, I will test this as soon as ad-freiburg/qlever#3199 is merged.

Along the way, I added some additional tests which uncovered 3 bugs which are now fixed:

• Because of a padding overflow, the meter distance computation was incorrect between XSortedCollection when the withinDistance threshold was not infinity, but very large. Essentially, all padded x coordinates then collapsed to DBL_MAX, making it impossible to sort them.
• A withinDist check between segments and boxes forgot to check the case where the segment was completely contained in a box
• The rewrite from 2 weeks ago which dropped the explicit build of a deferred OUT event queue had a bug which caused some deferred OUT events to be lost

[patrickbr]

There are now two types of errors left in the meter distance computation (covered now by tests which are for now commented out):

1.) We currently assume that the meter distance between a point A and a line segment S is the distance between the projection of A onto S and A. This is not true for segments spanning large latitude ranges. It can be mitigated a bit by taking min(dist(A, endpointS1), dist(A, endpointS2), dist(A, projectAonS)).
2.) Distances where the geodesic crosses the antimeridian (Datumsgrenze). This is a known issue caused by the sweep itself (the sweep never sees these candidates). Mitigation discussed with @hannahbast a few weeks ago is a recomputation of the distance with one side shifted by one width of the world (we can detect cases where this could happen: if the bounding box of both pairs is wider than world width / 2).

[patrickbr]

The remaining 2 error sources will be separate PRs.