<mutex>: Make _Mtx_internal_imp_mirror more closely match _Mtx_internal_imp_t

[cpplearner]

<mutex> doesn't need to know the layout of the critical section member. Specifying the layout is both unnecessary and error-prone (if we ever decide to change stl_critical_section_win7).

This also makes it possible to verify that _Critical_section_size matches stl_critical_section_max_size.

This fixes a bug on UWP where locking a mutex could throw a bogus exception.

[StephanTLavavej]

No change requested, note to other reviewers: I know this looks really really scary, but I believe it's a good change. This doesn't control the layout, it's just trying to mirror it (hence the name) so the header can directly access _Count. We are now mirroring it exactly:

STL/stl/src/mutex.cpp

Lines 39 to 48 in c8d1efb

	struct _Mtx_internal_imp_t { // ConcRT mutex
	int type;
	typename std::_Aligned_storage<Concurrency::details::stl_critical_section_max_size,
	Concurrency::details::stl_critical_section_max_alignment>::type cs;
	long thread_id;
	int count;
	Concurrency::details::stl_critical_section_interface* _get_cs() { // get pointer to implementation
	return reinterpret_cast<Concurrency::details::stl_critical_section_interface*>(&cs);
	}
	};

The header doesn't care about the details of what's stored within the aligned storage, so we don't need to separately describe the vptr and the class data members within. (This also permits further refactoring as described in the PR comments, but it's a good simplification even aside from that.)

The other simplification is that we can now mention the same "size" as primitives.hpp does, which includes the vptr. This avoids having the numbers all be different by 4 bytes for 32-bit and 8 bytes for 64-bit.

[StephanTLavavej]

No change requested, note to other reviewers: I know this looks really scary too, but we had already messed up UWP as @cpplearner verified in #3763 (comment) . This PR fixes things. Note that stl/inc's idea of the necessary size is not changing, so user-compiled code remains binary-compatible. What's happening is that the separately compiled STL DLL/LIB is now performing layout for UWP that matches what the headers expected.

The actual layout mostly didn't matter, because the interface is a flat C API, except for two things:

1. The space consumed needs to be less than or equal to the space provided by the header, and for UWP we are increasing the smaller MEOW_vista size consumed to the larger MEOW_concrt size which exactly matches the header, and
2. The location of the _Count needs to match, which it does after this PR.

[StephanTLavavej]

I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thanks for this extreme cleanup that ended up finding and fixing a bug! 🧹 🐞 😻