Use rtree for large polygons

[systemed]

This is a revival and reworking of #323.

The bounding boxes of large polygons (e.g. ocean) are stored in an rtree data structure rather than for each individual z14 tile. We then query this rtree when writing out each tile, and add any objects we find.

Tests with a couple of smaller areas (Devon and Maine) suggest little to no performance impact.

[systemed]

With the acid test of Antarctica and no bbox specified, memory consumption is halved (yay!) but execution time is doubled (boo!).

I suspect much of the slowdown is due to the situation outlined in #323 (comment) where we're processing the polygon for all tiles which intersect its bounding box. Previously we were only processing those tiles which cover the polygon (as per fillCoveredTiles in coordinates.cpp).

Options to investigate:

• use a faster clipping algorithm (boost.geometry intersection is perhaps too generalised for our rectangular clipping case)
• store a tile bitmap with each rtree (as a vector, though this of course will increase memory consumption)
• cut into smaller rtrees, maybe with some sort of binary divide algorithm
• split the largest polygons into multiple tiled polygons on initial read (e.g. z8 tilesize + a buffer)
• add multipolygon constituent polygons separately in OsmLuaProcessing::setRelation

[systemed]

More tests with Antarctica:

• v2.3: 7hr30 time, 18.6Gb RAM
• rtree3: 14hr08, 8.9Gb (Use rtree for large polygons #479)
• fast_clip: 2hr10, 18.6Gb (Use faster bbox-specialised clipping algorithm #482)
• rtree3 + fast_clip: 2hr59, 8.9Gb

With Europe (using --store):

• fast_clip: 4hr34, 52.2Gb
• rtree3 + fast_clip: 4hr27, 50.1Gb

I think that's a strong case for merging this. It makes a big difference to RAM usage in the polar regions; generally it's neutral on performance; and although there is a performance impact for Antarctica, #482 reduces it and arguably it's worth it for the RAM saving.