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.
Add logging to show the yum repo definition

We're getting some test failures due to not being able to access
the puppetlabs development yum repo (s3?).  This commit
simply adds logging to show the repo configuration, which should
help us to troubleshoot this kind of error going forward.
Merge pull request #638 from cprice404/bug/burgundy/dev-repo-failure

Add logging to show the yum repo definition
Move remaining `paged-query-to-vec` logic into `query` namespace

This commit continues the refactor of the original `paged-query-to-vec`
implementation by removing the remaining bits into the `query`
namespace, along with the count logic that had already been moved
over.
Move `paging` namespace from `http` to `query`

It seems like more of the functionality that is encapsulated
by the new `paging` namespace relates to query-ish stuff than
to specifically http-ish stuff, so this commit just moves
it to the `query` namespace.
Merge pull request #636 from cprice404/feature/burgundy/paged-query-record-counts

Add support for requesting 'total record count' when issuing paged queries
Merge pull request #637 from shakedown/dev/burgundy/pe950-event-counts-endpoint

Dev/burgundy/pe950 event counts endpoint
(PE-1306) Add paging support for event counts endpoint
Merge pull request #639 from cprice404/feature/burgundy/PE-1306-paging-event-counts

Feature/burgundy/pe 1306 paging event counts