<atomic>: Use new 64-bit interlocked intrinsics on x86

[StephanTLavavej]

Microsoft-internal MSVC-PR-240462 merged on April 26, 2020 and is available in VS 2019 16.7 Preview 3 (I haven't checked whether it's available in Preview 2; it added the macro __MACHINEX86_ARM_ARM64 to intrin0.h).

This implemented 64-bit interlocked intrinsics for x86, emitting slightly smaller codegen than was possible before. They aren't dramatically more efficient, but they're still worth using, as I understand it.

The following intrinsics are now unconditionally declared by intrin0.h (__MACHINE means "all architectures" including x86/x64/ARM/ARM64):

__MACHINE(__int64 _InterlockedAnd64(__int64 volatile * _Value, __int64 _Mask))
__MACHINE(__int64 _InterlockedDecrement64(__int64 volatile * _Addend))
__MACHINE(__int64 _InterlockedExchange64(__int64 volatile * _Target, __int64 _Value))
__MACHINE(__int64 _InterlockedExchangeAdd64(__int64 volatile * _Addend, __int64 _Value))
__MACHINE(__int64 _InterlockedIncrement64(__int64 volatile * _Addend))
__MACHINE(__int64 _InterlockedOr64(__int64 volatile * _Value, __int64 _Mask))
__MACHINE(__int64 _InterlockedXor64(__int64 volatile * _Value, __int64 _Mask))

I am uncertain as to whether Clang recognizes these intrinsics for x86.

Example of code that's currently special-casing x86:

STL/stl/inc/atomic

Lines 1070 to 1078 in 5e3423a

	#ifdef _M_IX86
	_Ty fetch_add(const _Ty _Operand, const memory_order _Order = memory_order_seq_cst) noexcept {
	// effectively sequential consistency
	_Ty _Temp{this->load()};
	while (!this->compare_exchange_strong(_Temp, _Temp + _Operand, _Order)) { // keep trying
	}
	return _Temp;
	}

STL/stl/inc/atomic

Lines 1123 to 1129 in 5e3423a

	#else // ^^^ _M_IX86 / !_M_IX86 vvv
	_Ty fetch_add(const _Ty _Operand, const memory_order _Order = memory_order_seq_cst) noexcept {
	long long _Result;
	_ATOMIC_CHOOSE_INTRINSIC(_Order, _Result, _InterlockedExchangeAdd64,
	_Atomic_address_as<long long>(this->_Storage), static_cast<long long>(_Operand));
	return static_cast<_Ty>(_Result);
	}

[AlexGuteniev]

Yes, looks like they are slightly more efficient.
And clang supports them too (with the same slightly better efficiency).
The best part is still code removal. no, unfortunately clang does not support them, I've ran cl instead of cleng-cl