Improve performance of quadtree point-to-polyline join

[trxcllnt]

Rewrites quadtree_point_to_nearest_polyline via thrust in the style of quadtree_point_in_polygon to get a 5x speed boost.

Benchmarked locally with NYC taxi 169M float32 points (RMM pool mode enabled):

quadtree_point_to_nearest_polyline (before)
1min ± 10.4 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

quadtree_point_to_nearest_polyline (after)
9.49 s ± 15 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Timings for every routine in the benchmark after these changes:

quadtree_on_points
66.2 ms ± 64.3 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

polygon_bounding_boxes
322 µs ± 375 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)

join_quadtree_and_bounding_boxes
11.4 ms ± 8.19 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

quadtree_point_in_polygon
5.48 s ± 54.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

polyline_bounding_boxes
258 µs ± 2.37 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

join_quadtree_and_bounding_boxes
11.5 ms ± 17.5 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

quadtree_point_to_nearest_polyline
9.49 s ± 15 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

[thomcom]

Mind iterating on this one's passing status when you get the chance @trxcllnt ?

[trxcllnt]

@thomcom yeah for sure. We might also want to wait on this PR because, while it's faster, it requires allocating much more temporary memory than the current implementation. I think it's possible to apply some of the techniques in the hausdorff iterator to eliminate that extra memory, but I'd need to explore it in depth.

edit: The new implementation that doesn't use as much intermediate memory done in e79caa9 🎉

[trxcllnt]

@harrism I re-requested your review for the new version of quadtree_point_to_nearest_polyline.cu

[trxcllnt]

rerun tests

[harrism]

@harrism I re-requested your review for the new version of quadtree_point_to_nearest_polyline.cu

I totally missed this. I'm sorry.

[harrism]

Looks great. Performance looks great. Several comments, but only one absolutely required change (missing stream sync).

[trxcllnt]

rerun tests

[harrism]

Just a couple more fixes.

[trxcllnt]

@gpucibot merge

[cwharris]

I had questions regarding how the tests were updated due to the new sortedness of the outputs, and @trxcllnt answered those offline. basically, user's weren't guaranteed any sortedness prior to this change, and now we are sorting the output ascending, so no breaking change.

lgtm.