Filter by geometries by bbox

I ran the slowest/most intense benchmark (query: all things - dense nine tiles) on OS X using node bench/vtquery.bench.js --iterations 5000 --concurrency 1 and a patch to disable all other tests besides query: all things - dense nine tiles. Then I profiled in Activity Monitor during the run.

What I see is:

• The majority of time is taken (nearly 40%) in the thread is in mapbox::vector_tile::extract_geometry due to calls to new and delete (memory allocation and deallocation)
• Then another 10% is spent in deallocating the geometry objects created by mapbox::vector_tile::extract_geometry which show in profiling as a delete call inside mapbox::util::detail::variant_helper<mapbox::geometry::polygon ... (which I think is the mapbox::geometry_base at https://github.com/mapbox/geometry.hpp/blob/96d350510c0e6738a903be40e8138c7305f3e33f/include/mapbox/geometry/geometry.hpp#L23)
• Then another 10% is spent in running mapbox::geometry::algorithms::detail::closest_point
• The remainder is tiny %s of various things include vtzero (like vtzero::layer::next_feature())

My interpretation is that:

• Parsing with vtzero is extremely cheap
• Running closest_point is also pretty cheap
• Decoding into mapbox::geometry objects is expensive due to memory allocation and deallocation

And therefore our overwhelming bottleneck (where > 50% of the time is taken) is mapbox::vector_tile::extract_geometry (https://github.com/mapbox/vector-tile/blob/97d8b89fe635f117ce7de25790028a65d9ce5172/include/mapbox/vector_tile.hpp#L15)

So, to reduce the latency of scenarios like this (large radius and multiple tiles) we'll need to speed up mapbox::vector_tile::extract_geometry.

Profiling output: https://callgraph.herokuapp.com/76849341d35452543e35c504964dcb94#thread-6

/cc @mapsam @flippmoke

Start with bench/vtquery.bench.js and run the documented node bench/vtquery.bench.js --iterations 5000 --concurrency 1 benchmark for query: all things - dense nine tiles. Profile the path through mapbox::vector_tile::extract_geometry, including geometry allocation and deallocation, and compare it with closest_point and vtzero calls. Done means reducing latency for large-radius, multiple-tile queries without changing query behavior.