list-keys cursor should be a resource

[pchickey]

In the current spec the bucket.list-keys operation and associated key-response struct gives a cursor: option<string> as a mechanism for implementing pagination. This introduces several problems for implementors:

1. How long does the implementation have to keep a continuation around for future pagination? This could potentially be very costly in terms of memory and may create consistency issues.
2. What happens if the implementation is given a cursor that it doesn't recognize?
3. What sort of information does the implementation put into the cursor string? How are we sure that implementations won't do something improper with that information, e.g. parse it for hints or otherwise rely on its contents, creating a portability problem?

All of these problems are solved by changing from an option<string> to, instead, defining a new resource cursor { next: func() -> result<key-response, cursor-error> }, changing key-response to contain an option<cursor>, and eliminating the cursor: option<string> argument from list-keys:

1. The implementation keeps track of the information required to return more values around until the resource is dropped, and can return an error in the case of insufficient memory, consistency issues, etc
2. Resources are unforgable
3. Resources are opaque

[thomastaylor312]

I think this supersedes #47. @lann would this address the concerns you had there?