[BUG] Use shared thread pool for multiple running instances of df on pyrunner

[jaychia]

1. Fixes the thread pool aspect of Do correct resource accounting if running multiple dataframe collections in the pyrunner #2493 by lifting the thread_pool from a local per-generator variable to a shared self._thread_pool in the singleton runner
2. Fixes the shared resources aspect of Do correct resource accounting if running multiple dataframe collections in the pyrunner #2493 by lifting the inflight_tasks_resources and inflight_tasks to shared variables in the singleton runner

The second part of this is a little dangerous because of the way these variables are used that can introduce a potential race condition:

1. self._can_admit_task checks against the inflight_tasks_resources to see if a task can be admitted
2. If so, we then proceed with submitting a task to the thread pool and updating inflight_tasks_resources

If another iterator is somehow able to update inflight_tasks_resources between steps 1 and 2, then our resource accounting would fail. However, I think this should never happen because our generators are not pre-emptable, and I don't think this race condition is possible.

[samster25]

I don't know if the id is guaranteed to be unique across dataframe executions?
let's add an assert that

next_step.id() not in self._inflight_tasks_resources

[jaychia]

Just checked: I think it should be

We have a singleton ID_GEN = itertools.count() that is used to generate the IDs, and it is supposedly threadsafe thanks to the GIL.

[jaychia]

(Also added the assert)