[wip] Alternative pagination idiom

I wasn't completely happy with the pagination idioms that I started in #186 - it requires a lot of boilerplate for each resource collection, including redoing the result type parse. This is an alternative approach that I'm presenting for comment.

## Pros

I think that this approach is marginally cleaner for clients; since I'm making `Pager` a concrete type, I can attach `EachPage` and `AllPages` as methods, which saves users from needing to create intermediate variables. It also more strongly prevents users from iterating over only the first result page, since the return type of the `List` method is a `Pager`, not a `Collection`.

Collection implementors now only need to implement two methods: `NextPageURL` and `Concat`. We can have re-usable iteration logic by providing utility functions that can be delegated to by `NextPageURL`, like `gophercloud.NextLinkedPageURL`.

## Cons

I'm assuming that pagination is always accomplished by varying the URL. If there's an API that does something weird with headers this won't work without changes.

We're still duplicating the logic of URL generation. This could be worked around by attaching a private method to the result type to generate it, and stashing the `ListOpts` in the `Collection`, for example.

`Concat` remains awkward and I'm not sure how it jives with @jrperritt's movement toward deferring the interpretation of result types into `Extract` methods.