<memory>: common spin lock in atomic_load/store for shared_ptr can lead to priority inversion

[BillyONeal]

This is a feedback report from some Xbox team folks: https://developercommunity.visualstudio.com/content/problem/716238/common-spin-lock-in-stdatomic-loadstore-for-shared.html

On the Xbox OS, the system is limited to 1 thread, because the other threads on the machine are dedicated to games. This means the STL's detection for that spinlock thinks it is on a multiprocessor machine, and uses spinning behavior accordingly. However, if a low priority thread currently holds the spinlock, a higher priority thread might spin forever and deadlock the system. There's none of the usual mitigation for priority inversions and similar like the platform locks have.

We should consider using WaitOnAddress for all STL spinlock primitives on Windows 8 or later, and/or replacing some of the spinlock primitives with SRWLOCK (which does its own spinning, and in the uncontended case is indeed acquired with a single CAS) on Windows Vista or later. That would engage the platform's priority inversion mitigations (and would completely resolve the Xbox team's problems because they get to assume Windows 10 or later).

[BillyONeal]

Closing this one because I think my writeup in #370 is better