Cool Idea: Cursor Pump to Prevent Buffer Underruns

Been thinking about `Cursor` a lot recently.

One of the things I see with the current implementation is, every time the consuming thread reaches zero-buffered items the consuming thread has to:
1. `await` for the `CONTINUE` `Response` if it's not already here (maybe it consumed things pretty fast)
2. If the `Response` is present, move the response data into a cursor's internal buffer
3. Fire off a `CONTINUE` if needed.

Essentially, we have to do some extra work every time we underrun the internal cursor buffer.

Not saying it's bad, but if we had a lil micro task that fired from the consuming thread when the internal buffer reached a "low water mark" threshold, the micro task would go out and work with the `Connection` to pull in cursor items as fast as possible to refill the internal cursor buffer up to a "high water mark" threshold.

Worst case, cons: The consuming thread is just way too fast at consuming cursor items and the server is being a slow poke. Having a system like this would lead to unnecessary overhead with things like `ConcurentQueue`.

Best case, pros: The consuming thread has very little "cursor maintenance" to do, and is hardly blocked or awaited on.

Maybe we could have the best of both words, two cursor implementations, and let the user pick.

So, when the user calls `RunCursor` run helper, they can pass a parameter that specifies they want a cool `Cursor` with a micro task pump:

```
Query.RunCursor(conn, {the cursor I want is a cursor
with a micro task pump for dis query, and here
is the high water mark and low water mark});
//hell yeah.
```

:boom: cool. maybe it doesn't matter to ppl, but still bad-ass cool.

:tulip: :rose: [**_"Sciuri, sciuri... sciuri di tuttu l'annu ..."**_](https://www.youtube.com/watch?v=TVPTX30Qw8s)

Start by reading the current Cursor, Connection, and Query.RunCursor implementations to understand how CONTINUE responses and the internal buffer are handled. Define the high- and low-water behavior, the user-facing choice of cursor implementation, and the tests or benchmarks needed to show that cursor consumption avoids unnecessary underruns.

Written by the indexing model from the issue text.