Enable support for free-threading

[zsol]

Enable support for free-threading

This PR:

1. marks the libcst.native module as free-threading-compatible
2. replaces the use of ProcessPoolExecutor with ThreadPoolExecutor if free-threaded CPython is detected at runtime

This depends on #1294 and #1289.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• ci: start building cp313t wheels #1333
• -> Enable support for free-threading #1295

[ngoldbaum]

I'll look at this next week - thanks for merging my other PR!

Some other things came up but I'm going to come back to this next week.

[ngoldbaum]

I ran the test suite with unittest-ft and there are a lot of errors and failures. Unfortunately the default settings for unittest-ft run all the tests simultaneously, which makes it a little difficult for me to understand exactly where the issues are. amyreese/unittest-ft#21 might help.

I see some tracebacks inside unittest.mock, so there's probably thread safety issues in the way mock is used in the tests.

All that to say, I think I agree with #1295 (comment) that we should focus on multithreaded stress tests rather than trying to use the existing test suite as a stress test - we'll likely end up spending most of our effort on fixing races in the test suite itself.

For now I'll focus on writing a stress test that uses a thread pool to process many files simultaneously.

[ngoldbaum]

I doubt it'll be very elucidating (it's 1.5 MB...) but here's the full output from running unittest-ft on this branch, after rebasing on main: https://gist.githubusercontent.com/ngoldbaum/0390a6afadd0fa8ebd5d5dbefe0cfd88/raw/c6d1a205ffb19240fa7de8807ca92ef3c3082ad2/gistfile1.txt

[ngoldbaum]

Nice! I updated the tracking table too: Quansight-Labs/free-threaded-compatibility#215