Define writeIORef = atomicWriteIORef

Non-atomic writes from `Data.IORef` are a dangerous foot gun. We cannot easily deprecate them, but we can just define them via their atomic cousins like

```haskell
writeIORef = atomicWriteIORef
modifyIORef ref f = atomicModifyIORef ref (\x -> (f x, ()))
modifyIORef' ref f = atomicModifyIORef' ref (\x -> (f x, ()))
```

Does not break anything: types are the same.

If this feels too radical as in "my app is single-threaded in 2025, I don't want to pay for atomicity" we can guard it by `getNumCapabilities`:

```haskell
writeIORef ref val = do
n <- getNumCapabilities
(if n == 1 then oldWriteIORef else atomicWriteIORef) ref val
```

I can imagine theoretical cases when a multithreaded application uses `IORef`s local to each thread, so it is kinda (!) safe to use non-atomic writes, but I feel such cases are not performance-critical enough to make everyone's life more dangerous.

Start with the Data.IORef API and the behavior of writeIORef, modifyIORef, and modifyIORef'; compare them with atomicWriteIORef and atomicModifyIORef, including the proposed getNumCapabilities guard. Done means the committee has selected and documented an accepted behavior and its compatibility and performance implications.

Written by the indexing model from the issue text.