Update FileIO comments, documentation to match implementation

Documentation

Discuss thread: https://discuss.python.org/t/change-open-write-to-guarantee-all-bytes-will-be-written-or-an-exception-will-be-thrown/71082

1. FileIO behaves differently than its code comments around read and readall. Update the code comments to match current behavior
   • PEP 475, reads are retried in some cases
   • .readall() makes multiple system calls by design
2. Add documentation to open() builtin that buffering=0, which currently just says "disables buffering") changes how .write() behaves and may result in data loss as a result of a partial write (ex. gh-126606).
   • TextIO and BufferedIO (which are gotten via commonly used open('README.rst'), open('README.rst', 'rb')) retry partial writes providing a user a guarantee either all bytes will be written or an exception will be thrown.
   • FileIO is "Raw I/O" and by PEP-3116 design, as documented, and currently implemented does not retry partial writes.
   • Most the time, buffering=0 currently speeds up writing a file, but it can also result in corrupted files, ex. gh-126606 from using FileIO directly
   • I would like to try and change the behavior of buffering=0 to use BufferedIO but with a 0 sized buffer, and that is on my roadmap but will be a while (people use the flag for a reason / get benefit!). This will mean open() always returns an object which implements "Write all or throw exception" behavior.
   • Add warning / document existing behavior on open() in the meantime.

Linked PRs

• gh-129012
• gh-135328
• gh-150957
• gh-150958
• gh-150959

Comece revisando os comentários do código de FileIO e a documentação do builtin open() vinculada na issue; em seguida, inspecione os PRs vinculados gh-129012, gh-135328, gh-150957, gh-150958 e gh-150959. Considera-se concluído quando os comentários descreverem o comportamento atual de read/readall e a documentação de open() explicar claramente buffering=0 e o comportamento de perda de dados em gravações parciais.