[Feature Request] Support single-page fetching for list workflows

[cretz]

Describe the solution you'd like

Currently the enumerable doesn't allow you to provide a next page token if you want to get the next page later. Need a single-page form of list workflows.

[jeromepl]

I dug a bit into the internals of the coinbase temporal ruby gem and it looks like there an Executions object is always returned. This object is an enumerable with #next_page_token and #next_page public methods, so very similar to what I proposed in #285.

However what I don't like from the coinbase/temporal-ruby approach is that the return value of #next_page_token is ill-defined. If you call it before calling #each you will get the token that was passed as input to get the list of workflows (or nil if none was given), but if you call it after then you will get the token for the next page.

This leads me to think that we might not want to always return the same object type for #list_workflows, as in the case where no page_size is given, we would want to automatically traverse all pages and thus the what to return for #next_page_token while doing the traversal would be unclear.
This would leave us with two options:

1. Have two possible return types for #list_workflows, depending on whether page_size is nil or not.
2. Define a separate method for the "paginated" version of #list_workflows, for example #list_workflows_paginated.

[cretz]

I think I personally like 2 and add a list_workflow_page w/ optional page size and next page token, and alter list_workflows to just use that (and make the interceptor and such for just the canonical list_workflow_page). The result of list_workflow_page can literally be Temporalio::Client::ListWorkflowPage that is a Data of the items and the next page token (with the absence representing completion). This is on our near term backlog, but would also welcome contribution (e.g. just changing the existing PR).

[jeromepl]

I'll update my PR shortly 🙂

[cretz]

Solved in #285