🐛 fix(async-rw): give each task its own hold

[gaborbernat]

Tasks sharing one AsyncReadWriteLock or AsyncSoftReadWriteLock instance could enter the write lock at the same time. 🐛 The async wrappers run each sync call on an executor thread, and the sync lock tracks its owner per thread, so it counted every task as one owner and let each one nest into the existing hold. GIL builds show it too; I found it while investigating #744.

The fix tracks ownership per task, as aiorwlock does. A table in _async.py sits in front of the sync lock; it queues a task that has to wait and nests a task into a hold it already has. Tasks share a read hold, and a writer waits for the other holders to leave, with waiting writers ahead of new readers so a stream of readers cannot starve them. Only a task's first acquire and last release reach the sync lock, so the SQLite and filesystem calls stay unchanged. Upgrade and downgrade still raise. Singleton wrappers over one path share the table behind a thread lock, so tasks on different event loops exclude each other as well.

With ownership per task, a task can release only a hold it acquired, and a release from another task raises RuntimeError. The how-to page covers asyncio.wait_for(rw.acquire_write(), 5) on Python 3.10 and 3.11, where the acquire runs in a child task that then owns the hold, and recommends the lock's own timeout or asyncio.timeout(). close() still releases every hold regardless of owner.