Various cleanups

[StephanTLavavej]

This is a collection of unrelated cleanups, structured as a series of commits for easier reviewing. I've separated out the pure comments/formatting cleanups (#2136), test fixes (#2137), and product fixes (#2138, #2139), leaving these commits which alter syntax but don't significantly change behavior. The user-visible changes are to <stdatomic.h> and (almost invisibly) <experimental/coroutine>.

• Remove unused __DOUBLE_EXPONENT_BITS/__FLOAT_EXPONENT_BITS.
• We can directly include <Windows.h> now.
  • This was working around a WinSDK bug which has been fixed. This is our test code, so we don't have to worry about users with old WinSDKs.
• Change typename CharT to class CharT.
  • This was the only inconsistent occurrence in product code.
• Stylistically reorder exception_ptr operators; provide only necessary ones for C++20.
  • This should provide the same behavior to users.
• Construct tags with empty braces.
• Capitalize template parameters.
• Change size() == 0 to empty() for strings.
• Remove unnecessary parens in (b.func) (b.data).
• Avoid unnecessary auto.
• libcxx: Unskip C++23 tests (will be "unsupported" until tests.py should map /std:c++latest to 'c++2b' #2001 is fixed).
• Emit an error when compiling stdatomic.h as C.
  • Followup to Implement P0943R6 Supporting C Atomics In C++ #2008. This will make it easier for users to diagnose issues like MSVC's C++23 <stdatomic.h> breaks the CoreCLR build dotnet/runtime#57618 .
• Simplify stoi(): int and long are the same size for us.
  • Thanks to @cbezault for noticing this.
• Use deprecated attributes in <experimental/coroutine> (improves syntax highlighting).
  • This slightly clarifies the messages emitted to users. I didn't think it was worth centralizing these in yvals_core.h, or numbering them.
• Demacroize <xthreads.h> size/alignment constants.
  • These were already _Ugly instead of _UGLY_MACROS. There are other macro constants but I didn't want to perform invasive renamings for them at this time.

[barcharcraz]

will this break icc? I mean I don't care, but that may be why we checked this in the first place

[StephanTLavavej]

Good question (as we try to avoid gratuitous breaks). It shouldn't - the Intel C++ Compiler issues we've encountered have involved 80-bit long double (and occasionally new compiler intrinsics). AFAIK, there are no issues with our LLP64 assumption that sizeof(int) equals sizeof(long) equals 4 (that assumption is widespread throughout our codebase).

This was originally being checked because MSVC's STL was licensed from Dinkumware, where the upstream source code was portable to many platforms.

[StephanTLavavej]

I'm mirroring this to an MSVC-internal PR. Please notify me if any further changes are pushed.