Add support for .params; create CollectionRequest constructor

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.
Add _filter generation to all endpoint handlers

Since all methods now extend from CollectionRequest, they should all
have access to the _filter object so that no error occurs if .filter()
is called on the request chain.
Add CollectionRequest .page() method and corresponding tests
Add tests for .context() and .edit()
Add .context() and .edit() parameter methods to CollectionRequest
Add tests to demonstrate that page and context wrap .param()