Merge pull request #633 from nicklewis/faster-report-timestamps

Use a faster query to retrieve report_timestamp
Merge pull request #629 from cprice404/feature/burgundy/paged-queries

Paged query support
Change return value of `paged-query-to-vec` to a map

`paged-query-to-vec` needs to be able to return the total count
of rows that would have been returned by a paged query, in
addition to the actual result set.  In order to accomplish this,
we need to change the return type from an array to a map.

For now, this map contains just a single key, `:results`, whose
value is the same vector of results that the function was previously
returning.  In a subsequent commit we'll add a `:count` (or similar)
key that can be optionally populated with the count data.
Add support for `count?` flag in paging code
Update facts/fact-names to support paging with counts
Update events endpoint to support paging with counts
Update reports endpoint to support paging with counts.
Add support for counts on paged queries on node endpoint
Add support for counts for paged queries on resources endpoint
Update docstrings and docs re: paged queries

This commit updates the docstrings of some of the functions in
the `query` namespace which used to return a vector of query
results but now have a slightly more complex return type.

This also updates the end-user documentation to indicate how to
use the new `count?` query parameter to request result counts
for paged queries.
Refactor `paged-query-to-vec` into two functions

This commit pulls out the logic for dealing with the "count" portion
of the paged query implementation into a new function
`execute-query`, which lives in the query namespace.
Rename `count?` query parameter to `include-count-header`

Using a question mark in a query parameter name is probably not
the nicest thing in the world to do, even if it does make the
intent of the parameter infinitely more clear.  :)
Refactor `json-paged-response` into more general `query-result-response`
Rename `:results` key in query result map to `:result`

After discussion, we decided that `:result` was a better name for the
key in the query map because in the general case there is no reason
to assume that the result must always be a collection.  This
makes it a bit more obvious that we can write general functions,
like the `query-result-response` function in the `puppetdb.http`
namespace, which can do things like simply convert the `:result`
to JSON without being concerned about the specific details of
its contents.