Limit tiles by size, prioritizing features by a numeric property

[dabreegster]

This gets much closer to providing value over tippecanoe -- when a tile gets too big and we have to sacrifice something, we can do it by a numeric feature property.

The tile sizes aren't respected with the current implementation, though:

Added 22922 features into 7/62/39, costing 555270 bytes (skipping some features after hitting size limit)
Added 22922 features into 8/125/79, costing 555270 bytes (skipping some features after hitting size limit)
Added 22922 features into 9/251/159, costing 555270 bytes (skipping some features after hitting size limit)
Added 4570 features into 10/502/318, costing 108612 bytes
Added 22842 features into 10/502/319, costing 552732 bytes (skipping some features after hitting size limit)
Added 178 features into 10/503/318, costing 3830 bytes
Added 8897 features into 10/503/319, costing 213575 bytes

That's because only the encoded geometry counts towards the size estimate, not any properties. Calling layer.compute_size() repeatedly doesn't work either though, because it's incredibly slow to encode the protobuf constantly.

[dabreegster]

Moving this code to another repo. This is merged in as https://github.com/Urban-Analytics-Technology-Platform/lines2pmtiles/commit/2d00d16658284a4fcade993351ccb07f912523ae