`list-keys` cursor should be a resource

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

Start by reading wit/store.wit, especially the key-response definition at lines 44-46 and bucket.list-keys at lines 104-120. Compare the current string cursor model with the proposed cursor resource and document the required spec changes, including pagination and cursor-error behavior.