Implement resource collections

This change implements support for resource collections that mimic Django's
query set API so that things like this are possible:

    >>> s3 = boto3.resource('s3')
    >>> for bucket in s3.buckets.all():
    ...     for obj in bucket.objects.limit(100):
    ...         print(bucket.name, obj.key)

Implements the following for collections:

* Non-iterable collection manager (e.g. `s3.buckets`)
* Iterable `ResourceCollection` base class (e.g. `s3.buckets.all()`)
* Chainable resource collection API (via clones)
* Filtering via `.filter(Arg1=1, Arg2=2)`
* Control item count via `.filter(limit=20)` or `.limit(20)`
* Control page size via `.filter(page_size=100)` or `.page_size(100)`
* Indexing and slicing (e.g. `s3.buckets.all()[2:5]`)
* Exposing `all`, `filter`, `limit`, and `page_size` on the manager
* Updated documentation

Also adds tests for all the relevant features. Note that batch actions
are *not* included in this change.

cc @jamesls, @kyleknap, @garnaat 
Right now in the implementation there is no difference. I've done this to simplify the code, but we can split them into two methods if you think it is warranted.

The reason that Django does this is because `filter` creates new `Q` objects that get serialized into pieces of an SQL string for finally querying the database. We don't really have a need for this, so both `all` and `filter` really just set a bunch of params on our collection clone.

I *think* we wanted to keep `all` as a way to make code look less awkward (e.g. no blank `bucket.objects.filter()` calls since `bucket.objects` isn't an iterable itself).

If you're just asking about the specific implementation, I'd ask what advantage we get by making two separate methods.