Some resources always have _some_ level of activity every time they're
checked, which would ordinarily prevent the resource from ever being
considered "caught up", preventing the connector from exiting.

If the LogCursor is a date-time, then additionally consider the task to
be idle if the LogCursor is less-than `interval` old (where interval is
configured on the ResourceConfig), and sleep until the cursor is
`interval` old before issuing a successive fetch.

Much like FetchChangesFn, FetchPageFn is now an AsyncGenerator which
yields documents, checkpoint-able PageCursors, or completes an
iteration of a resource.

This refactoring is consistent with recent updates to FetchChangesFn,
and is motivated by use cases where the fetched "page" could be quite
large and itself composed of multiple concurrent data fetches,
implemented as constituent AsyncGenerator instances.

By using an AsyncGenerator, such an implementation can immediately
yield from across those concurrent fetches as data arrives such that
data is spilled to disk and memory pressure kept low. Then, when the
scatter / gather data fetch completes, the entire "page" is
checkpointed.