Performance issues when using multiple threads due to regex scratch space contention

[orf]

There appears to be a lot of mutext contention when using libcst with multiple threads. I discovered this while parsing a lot of code across only 8 threads on my local machine. I was averaging about ~1.5k files per second with a flamegraph that spent 80% of the time inside TextPattern.match_len:

This is because the scratch-space for each regex defined in libcst is shared between all threads. As a proof of concept I switched the regex compilations to use thread locals, and immediately saw a ~10x performance jump to ~12k files per second:

This is because the pattern scratch-space is no longer shared between threads, and thus there is no contention.

I'm happy to make a pull request with these changes, but I wanted to spur a discussion here because the trade-offs are not clear. If you create/destroy a lot of threads then this change would have a negative impact, however if your threads are long-lived and you are doing a lot of individual parsing calls then this is a great benefit.