Pagination

This adds pagination support for all non-singleton GET routes.  

This is very basic pagination that simply allows the API consumer to specify a page and count in the querystring in order to limit the results.  There is no snapshotting of data, so if deletions or additions occur between calls, the pages may have redundant or insufficient data.  Each call to a paginated function also returns a _pageData object in the body, which contains the current page, count per page, and the total number of objects available.

Note that there is no pagination going on yet at a deeper level than simply filtering the results returned (the database is still being queried for the full result set).
Heh, yeah, this is one of those things that looked more wrong to me the more I worked with it, so I'm happy to change it.  My original thought was to do this to avoid conflicting with a "real" data element that happened to be named pageData, since I wasn't too keen on changing the entire structure of our responses by tucking all of our current results inside a "results" field or something.  That said, this is obviously a largely theoretical concern, since the likelihood of our responses needing a field called pageData that isn't related to pagination is probably not too high.  I'll change these, it's gross.