filebuf: make unlocking atomic

When renaming a lock file to its final location, we need to make sure
that it is replaced atomically. There are situations where this is not
possible in all OSs, so we try to make the best of it by removing the
target file in cases where we do not have a lock.

---

Our current behaviour was raised in #2211. This behaviour change was introduced in 1db9d2c3 as a workaround for Windows filesystem semantics.

@paulcbetts (as author of the patch), as this seems like a Windows issue, should be move the unlink into the Win32-specific `p_rename()` as @phkelley suggested in the other issue, so we can forgo this call in the rest of the filesystems?