Reads and writes of volatile aligned words are automatically blessed with
atomic acquire and release semantics at compile-time by MSVC, leaving only
CPU operation reordering to worry about. x86 and x64 CPUs will not reorder
the operations, but MSVC targets Xbox, which notably will reorder them,
thus I added fences out of an abundance of caution. While Cap'n Proto
likely will not compile for Xbox as-is, I would hate for someone to port
it only to have to debug obscure atomic-operation-related crashes later.

I implemented the fences using std::atomic_thread_fence rather than
MemoryBarrier(), because including windows.h in raw-schema.h is a
non-starter, and it would be silly to reimplement it with in-line assembly
and intrinsics for every targeted CPU when <atomic> is available.

Another possible implementation could have been to use the InterlockedXxx
functions, however they present a few issues:

1. They're defined in windows.h. We could define them in terms of their
   underlying _InterlockedXxx intrinsics, but we'd need more #if blocks to
   handle both 32-bit and 64-bit pointers. If we go this route, it'd
   probably be better to go all-in and define some kj::atomic{Load,Store}
   functions.
2. We cannot implement atomic load-acquire semantics with them for const
   variables without const_casting.