More things I've noticed while modularizing the STL, updating the toolset, and reviewing code.

• As far as I can tell, <fstream> and <random> don't need to suppress warning C4127 "conditional expression is constant" anymore. I believe we've already converted the affected code to use if constexpr.
• In <codecvt>, finish converting all _Mymode tests to use if constexpr so we can drop the C4127 suppression.
  • Also, reorder one pair of conditions (for performance and clarity). It's safe to test (_Mymode & generate_header) != 0 at compile-time first, potentially skipping the runtime test of *_Pstate == 0u which has no side effects.
• In <regex>, convert _Cl_names::_Get() to use if constexpr. Also add _NODISCARD and noexcept.
• In <xlocnum>, use if constexpr instead of _Hex_float_precision specializations.
  • This code always returns 13 hexits, but I've kept the existing structure since it explains what's happening. (This may also affect the 80-bit long doubles that we don't officially support but also avoid gratuitously breaking.)
• <xlocmon> access control:
  • Drop repeated public: in _Mpunct.
  • money_get and money_put should say private: explicitly.
• Detach comments in <variant>'s get() and get_if().
• Also detach the comment in <xlocale>'s definition of locale.
  • This one doesn't look messy right now, but it'll wrap when I export the class.
• Add a newline after defining ATOMIC_FLAG_INIT.
• Use inline constexpr consistently in <execution>.
• Call abort() to avoid assertion crash dialogs.
  • libcxx's msvc_stdlib_force_include.h overrides _CRT_SECURE_INVALID_PARAMETER to call abort(). However, _STL_VERIFY shouldn't emit long strings for function names #2054 changed yvals.h to sometimes bypass _CRT_SECURE_INVALID_PARAMETER and call ::_invalid_parameter() directly. For reasons I don't currently understand, when my work machine upgraded to VS 2022 17.2 Preview 3, this emits assertion crash dialogs (whereas my home machine still doesn't). This happens when a few XFAILed libcxx tests have failing _STL_ASSERTs. I considered updating libcxx's force-included header to also override the new layer _STL_CRT_SECURE_INVALID_PARAMETER, but that's a fair amount of logistical effort - and I noticed that tests/std and tests/tr1 are also affected, including our header units test which doesn't want macros defined by force-included headers. Thus, I am simply introducing a new object-like macro that the 3 test suites can define on the command line.
  • I think we may want to reconsider how this machinery works in the future - it seems that we already emit _RPTF0(_CRT_ASSERT, mesg) to report the message. (Perhaps this does nothing for UI programs that don't have a console or file for such output?) Specifically, I wonder whether we should simply always abort() here. However, I don't want to perform such a significant change right now.
• Fix comments in the libcxx skip lists: the file is currently named msvc_stdlib_force_include.h, not msvc_stdlib_force_include.hpp.
• Categorize libcxx skips for random distribution tests.
  • Most of them are kurtosis/skew assertions, which may actually be bogus tests (like other such assertions mentioned in other skips). I've moved them from "likely STL bugs" to "not yet analyzed" and mentioned the assertions.
  • Two of them are bogus tests.
• structured_bindings.pass.cpp was XFAILed due to DevCom-1559808. Again for reasons I don't currently understand, when my work machine upgraded to VS 2022 17.2 Preview 3, this consistently emits an ICE (fatal error C1001) with a compiler crash dialog, which is extremely annoying. I'd like to mark this as SKIPPED, even though this will make it harder to notice if/when the compiler bug is finally fixed.