GH-116738: document thread-safety of bisect

[nascheme]

I don't think it makes sense to make these functions thread-safe. They are already unsafe when used in the default build. And, given that they can operate on any sequence object, trying to lock the sequence object doesn't make sense.

I added a unit test because I believe these functions should not crash or produce TSAN warnings when they are used on a sequence being mutated in another thread.

• Issue: Audit all built-in modules for thread safety #116738

---

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

[picnixz]

Possible suggestions:

• Use a .. note:: if you think users should know about it.
• Use a .. warning:: if you think users should be careful about it.
• Do not use either of them if you think it's just good that users know about it (a note or a warning is quite visible in the sense that it creates a box where the entire content is inside that box).
• Use a subsection about thread-safetiness. Or use a small warning box just saying that the functions are not thread-safe, and add a link to a section at the bottom of the page that contains more detailed explanations.

cc @hugovk

[nascheme]

Using "note" seems appropriate to me in this case. In the long term, I suggest it makes sense to have a thread-safety (or concurrency-safety) section for any module that has unusual rules (non-atomic functions, shared state). In the "warnings" doc, I added a "Concurrent safety of Context Managers" section to it. That's a case where the rules are quite complex and a dedicated section makes sense.