generate tasks within a kind concurrently

Start in src/taskgraph/generator.py around lines 76-89, where transforms are currently run serially for tasks within a kind. Investigate safe worker-thread or process approaches and when their setup overhead is worthwhile, then benchmark generation for the tests kind and smaller kinds. Done means transforms run concurrently without changing generated results and performance impact is measured.

In #5 we've discussed parallelizing the loading of kinds to improve decision task performance. One of the discoveries in that thread was that for Gecko (where we have the longest decision task), this would only incrementally improve performance. As it turns out, most of the work is inside of the test kind, and kind-level concurrency won't help there at all.

Something we could do to improve generate within a kind is to concurrently run transforms for individual tasks. This is currently done serially over here, and AFAICT, there should be nothing stopping us from running those across multiple threads or processes. It's unclear to me if this will be a massive win, but in a quick test it appears there are ~22,000 calls to transforms for the tests kind, so presumably it would be something.

We may need some sort of intelligent way to push these into worker threads/processes; it's possible that for kinds with just a few tasks that the overhead of setup/teardown would be more than the reduction we'd get from the concurrency. Perhaps a minimum number tasks should be needed before spawning workers (either an absolute number, or one relative to the number of workers we'd spawn, which would presumably be based on the # of cores available).