YT-24537: Prioritize writers in TReaderWriterSpinLock, rename old version to TWriterStarvingRWLock

Previously, it was possible that `TReaderWriterSpinLock` wouldn't let the writer through if there's a steady flow of readers.

This change addresses that by:
1. Prioritizing writers inside the spinlock by adding an additional `WriterReady` flag that writers set on arrival. This flag doesn't allow any readers to come through.
2. Adding the proper tests to verify this functionality, as well as spinlock's behaviour under forks.
3. Clarifying the documentation about spinlock guarantees
4. Adding a TLA+ model, formally specifying and verifying the guarantees of the new spinlock.
5. Renaming the old lock to `TWriterStarvingRWSpinLock`, and replacing all usages inside YT with the new version (renaming all usages outside of YT to the WriterStarving version).

This is a second attempt of REVIEW: 8233768, the first one was rolled back as it lead to deadlocks in user code with reentrant reader locks:
the case of `AcquireReader(thread0) -> AcquireWriter(thread1) -> AcquireReader(thread0)` is a deadlock, as `thread0` will not be able to acquire the lock (for the second time) before `thread1` frees writer lock, and `thread1` will not be able to acquire writer lock before the reader lock will be released by `thread0`, which won't happen until `thread0` acquires the lock for the second time. See/for more context and a real example of such situation. Analogous problem can happen with fibers: this is why you shouldn't allow context switches under the lock.

Wondering why this ugly name `WriterStarvingRWSpinLock` appeared in your beautiful code? No worries, if you are **sure** that you don't use reentrant locks or fiber switches under the lock, you can freely replace your usage with the new `ReaderWriterSpinLock`. The replacement is drop-in.

[nodiff:caesar]
commit_hash:97683f854defca00cc283f5a2a10a1730b3c9174

0 files changed, 0 insertions, 0 deletions