Since `getQueryResults` was already used to wait for the job to finish,
this avoids an additional call to `tabledata.list`. The first page of
results are cached in-memory.

Additional changes will come in the future to avoid calling the BQ
Storage API when the cached results contain the full result set.

Also, move to thread-local variables for values that were
intended to track parameters across methods.

…etQueryResults

startIndex is no longer passed to the iterator
It is used in the initial (cached) call to
getQueryResults