Fix typos

[ember91]

This has two goals: Improve the "typos" spell checker but also increase the quality of the cPython source code.

This was done using two spell checkers. Does this fix all typos? Most certainly it does not.

---

📚 Documentation preview 📚: https://cpython-previews--125473.org.readthedocs.build/

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[picnixz]

Please, make the diff smaller (with less files) and avoid touching anything that is related to runtime objects (e.g., class names, function names, etc). If you want to fix typos, you should only fix typos in comments or documentation but not in objects used at runtime.

I'm closing this PR since it's already a huge one and suggest to split changes with less files.

[picnixz]

I also suggest having standalone PRs if you only touch the documentation, unless something must be synchronized with a library file (that is, leave the .py files untouched and only touch the .rst files). Or only change .py files. Or only change .c files.

[terryjreedy]

(EDITED) I made PR ##125484 to fix the idlelib typos since I want them backported and know that they can be backported. Note that help.html is generated from the .html file generated from idle.rst, so the errors there must be fixed in the source. (It turns out they already were, but had not be propagated.) I verified that 'interruptable' should be 'interruptible'. Though misspelled code identifier should normally be left alone, I changed it.

[terryjreedy]

Changing suppressions_path: Tools/tsan/supressions.txt to suppressions_path: Tools/tsan/suppressions.txt is wrong if the filename is actually (mis)spelled as in the original. There other cases like this. You would have to report on the PR that you checked each on. Such changes should be in a separate PR.

At least half of the proposed changes are obvious misspellings with non-controversial fixes that I would be willing to review and merge if there were a PR or PRs with (only) such. But something like changing mutex would be swalled out to mutex would be stalled out is not obvious to me (I know nothing of mutex jargon) and I would not merge it.