We've accumulated inconsistency between using our _EXTERN_C macro and directly saying extern "C":

The macro used to be important when some of our headers were dual C and C++. Now that they're always C++, and that we don't expect to play special games with extern "C" in the foreseeable future, we should resolve this inconsistency and favor dropping the macro.

(In contrast, we're quite disciplined about _STD_BEGIN in product code, and I do want to play special games with it soon.)

• Replace: _EXTERN_C ... _END_EXTERN_C => extern "C" { ... } // extern "C"
• Add // extern "C" comments.
• Wrap stacktrace's function pointer typedefs in extern "C".
  • It doesn't really matter because typedefs are "transparent" (they don't create new types), but I believe it's desirable for the signatures of extern "C" functions to restrict themselves to mentioning only things that are within the extern "C" universe. During the initial modularization effort, I overhauled extern "C" functions to mention only extern "C" structs, where it did matter.
• sharedmutex.cpp: Move the _Smtx_t typedef within extern "C".
  • Again, it doesn't really matter for typedefs, but this is now consistent with stl/inc/xthreads.h:

    STL/stl/inc/xthreads.h

    Lines 21 to 28 in f392449

    	_EXTERN_C
    	using _Thrd_id_t = unsigned int;
    	struct _Thrd_t { // thread identifier for Win32
    	void* _Hnd; // Win32 HANDLE
    	_Thrd_id_t _Id;
    	};
    	using _Smtx_t = void*;

• Mark _Atomic_memory_order_meow as extern "C" to match vcruntime.
• Mark _C_meow_complex as extern "C" to match the UCRT.