Feature/types filter convenience method

Per Skype discussion with @rmccue, all main endpoints should have access
to filtering and pagination methods. Based on this, the strategy of
augmenting a class with filter methods by mixing them in to the object's
prototype seems shortsighted.

This commit changes the CollectionFilter module into a full constructor, CollectionRequest, and inserts it into the prototype chain between the existing endpoint methods and WPRequest. This creates the following hierarchy of functionality:

1. Endpoint-specific queries and path methods (Top Level)
2. Query-string construction, such as filters and pagination
3. Path generation, HTTP interaction

This also means we can store the _params functionality right on the CollectionsRequest object, since its behavior should be applied in all the same places as the existing filtering logic. Neither will be relevant to all queries, but there's no need to arbitrarily restrict where these query string-related methods can be called; jQuery doesn't prevent you from generating an invalid selector query, either.

This was all in the service of adding a `.type()` filtering method to `PostsRequest`; TODO are

- [x] `.page()`, for pagination
- [x] `.context()`, for editing (also add `.edit()` convenience method?)

Unlike `.type()`, `page` and `context` should exist on all collections (*i.e.*, they'll be put onto the CollectionsRequest prototype)