Fix slow road merging

[zerebubuth]

The tile 9/454/201 was taking a huge amount of time to render - several hours. This is due to the changes I made in #1703 to prevent intersections between lines being re-added as part of MultiLineString operations. According to the OGC spec, LineStrings within a MultiLineString may only meet at points, but this means we end up with way more points in the output than we need to accurately describe the geometry. Therefore, we split them up into several features, where each MultiLineString in each feature only contains non-overlapping LineStrings.

The algorithm I was using to do this wasn't efficient - it simply looped over all the features looking for intersections with previous features. And it worked OK on cities with a lower road density and lots of mergeable cross-shaped junctions, such as New York.

However, in Tokyo, where the tile was taking hours to render, there are 400,000 lines in the tile and the road network is not a grid, meaning there's less opportunity for merging.

Therefore, I replaced the previous algorithm with one that is more efficient for larger numbers of tiles. It works by indexing all the shapes rather than doing direct comparison. For large inputs, the shapes are additionally sorted by bounding box area and the index split between small and large. This means that the small-to-small comparisons are done more quickly (any given two small shapes are much less likely to intersect than a small and a large, or a large and a large).

Finally, we have been stripping name off roads at low zooms, but were not stripping name:* translations or official_name and similar "name-like" properties. This PR adds an all_name_variants parameter to drop_properties which tells it to treat name as if it's all name:* and variants. One drop_properties which was only dropping name was converted to drop_names instead. Dropping these might (slightly) increase mergeability and will decrease the number of properties stored in the tile.

[zerebubuth]

Oh, I probably should have mentioned the times; previously, the 9/454/201 was taking several hours to generate - I don't know exactly how many because I gave up waiting. After this PR, it still takes 30 minutes, which isn't awesome but much better than it was.

[rmarianski]

Do we want to pull this value from config? Or is this a good number that's not likely to change?

[zerebubuth]

Good point, thanks. I think it's a pretty good number to start with, but we might end up tweaking it later. I've made it configurable in 5889c36, with the default 15,000.