[wip] Mark-and-limit pagination and storage

I'm expanding the pagination work started in #200 to include the marker-and-limit pagination scheme, with the intention of expanding the existing storage implementation to use it.
> I don't know if you can do that in Golang (leave an interface partially defined so that implementors have to fill in the pieces)

Nope, sadly you can't. :disappointed: The reason that `Extract` isn't part of `Page` is because it can't be, because the result type is different for each collection. We couldn't even include it as an `[]interface{}` - to implement an interface you need to match type signatures exactly.

The `lastMark` function for `NewMarkerPage` is equally ugly, too.

> If that's not possible, could we reduce the footprint of the countPage closure by asking it as an argument to EachPage only? I can't find any more usages apart from that function, so do we need to define it as a required func on the Pager struct?

That's not bad - especially because we could define `Count` functions alongside the `Extract` ones that you can pass directly in:

```go
pager := services3.List(ListOpts{})
pager.EachPage(services3.Count, func (p Page) (bool, error) {
  // ...
})
```

What I'm going to try first, though, is to re-introduce the inheritance-by-embedding from my original take, but provide concrete, embeddable types for result types to embed. I've done a quick proof of concept to make sure that the type system works the way I think it does - I'll push some code out shortly that shows what I mean.