More efficient response format

Nobody has claimed this yet.

In profiling vtquery under load with @mapsam I recall seeing that the JSON response creation runs on the main event loop and takes a non-trivial amount of time to return as a JS object.

Given this fact there are several things we can consider that would speed up the response:

### Async json generation in threadpool

We could generate the JSON response async inside the thread pool (so inside [Execute()](https://github.com/mapbox/vtquery/blob/96c645b8cdac54c8af968188587a14c1535862f8/src/vtquery.cpp#L262) rather than on the main thread like is currently done (https://github.com/mapbox/vtquery/blob/96c645b8cdac54c8af968188587a14c1535862f8/src/vtquery.cpp#L390).

This would require serializing the JSON to a string and then passing the data back from the threadpool in the same way that we pass vector tiles back from the threadpool to the main thread in vtcomposite and vtshaver (as a node.Buffer).

### Compressing the JSON response

Now that we're working with a string, we could also gzip compress the JSON string in the threadpool before sending back. This could help speed up the transfer of the data to clients.

Start at src/vtquery.cpp, comparing Execute() around line 262 with response creation around line 390. Read the vector-tile handoff in vtcomposite and vtshaver for the thread-pool pattern and node.Buffer transfer. The scope is not settled between asynchronous JSON generation and compression, so confirm the chosen approach and benchmark that response work no longer blocks the main event loop.

Written by the indexing model from the issue text.