fix(base): keep <windows.h> out of the lock and file headers

[Force67]

Two base headers that reach nearly every file pulled in <windows.h> on Windows, and with it macros such as MemoryBarrier, near, far:

• spinning_mutex.h / mutex.h inlined their SRWLOCK calls and included base/win/minwin.h, which on mingw is all of <windows.h>. rx's renderer stopped compiling on mingw once its job system moved to base::Mutex (CommandList::MemoryBarrier became _mm_mfence). The Windows halves of SpinningMutex and SharedMutex move to threading/mutex_win.cc; the lock stays a single pointer (SRWLOCK's layout, zero-initialized like SRWLOCK_INIT). POSIX paths are unchanged and still inline.
• filesystem/platform_file.h included <windows.h> directly, on MSVC too, so every user of base::File got its macros; rx's world streaming header (a member named near) broke under MSVC. It now takes HANDLE from minwin.h, which forward-declares on MSVC. memory_mapped_file_win.cc, which had relied on it for the file-mapping API, includes <windows.h> itself.

mutex_test.cc includes these headers before anything else and fails to compile if a Windows macro follows them (the file.h check skips mingw, where minwin.h is <windows.h> by design), then covers SpinningMutex try/exclusion under contention and SharedMutex reader/writer exclusion (spinning_mutex_test.cc was empty).

base_unittests 1008/1008 on Linux and on mingw-w64 under wine.