Fix file rename race condition in lock implementation on windows

[jonatanklosko]

Fixes error reported in #14793.

Replaces File.rename/2, which is not atomic on Windows (the destination file can be briefly deleted), with a switch-file:

# We need a mechanism to atomically replace file content. Typically,
# we could use File.rename/2 to do that, however File.rename/2 is
# not atomic on Windows, if the destination exists [1].
#
# As an alternative approach we use a switch-file. The file content
# consists of 1 switch byte (either 0 or 1) and two content segments
# with fixed, equal lengths. The switch byte indicates which segment
# is currently active. To replace the file content, we write to the
# non-active segment and call :file.sync/1 to ensure the segment is
# persisted, then we toggle the switch byte. While we cannot write
# multiple bytes atomically (since they may reside in multiple disk
# sectors), if we toggle only a single byte, there is no intermediate
# invalid state, which gives us the atomic replace we need.
#
# Note that file content can be replaced only by a single process
# at a time.
#
# [1]: https://github.com/elixir-lang/elixir/pull/14793#issuecomment-3338665065

It's a bit of extra complexity, but it should effectively be a drop-in replacement for the current File.rename/2 and the overall algorithm doesn't change.

[jonatanklosko]

I bumped a version to make sure we don't try to read old lock files, since the expected format changed.

[jonatanklosko]

I picked an arbitrary limit. Ideally we would store OS PID it as an integer, but my understanding is that it's not guaranteed to be one.

[josevalim]

💚 💙 💜 💛 ❤️