Allow a pluggable layer than people can use to add durability and resiliency to losing queries that are long-lived

If the backend does not respond timely, it will cause zombie queries in bullet service. Bullet service keeps waiting for those zombie queries and never close the queries to close the HTTP connections. Eventually bullet service will run out of FD to accept new queries.

We need a way to cleanup zombie queries to fix this issue.

The WebService has not yet been updated to support Maps of Maps:
https://github.com/bullet-db/bullet-service/blob/bullet-service-0.4.0/src/main/java/com/yahoo/bullet/rest/schema/Column.java#L60

bullet-core version 0.4.0 added support for integers and floats, but this support is not yet reflected in the bullet Web Service. It should be added.

If bullet-record issue 12 has been completed, we can also add support for lists of primitives.

Add a max.concurrent.queries setting to be able to control the maximum number of queries in the system.

Return a 503 if too many queries are currently running.

Allow plugging in and reporting metrics

Fire and forget queries and read results asynchronously somewhere else

1. Expose a method to find out if a query is running right now and/or retrieve the QueryHandler
2. Expose a method to kill a query/all queries
3. Expose a method to send a custom PubSubMessage through the QueryHandler

Relates to #36. This should allow you to resubscribe back to a WS for an existing query