`<xloctime>`: Unnecessary export of bogus `time_get<char>::_Getvals(wchar_t, const _Locinfo&)`

time_get contains the following unusual code:

https://github.com/microsoft/STL/blob/852a3085906108045a3951064baaf4952f596e9e/stl/inc/xloctime#L175-L200

where _Maklocwcs is:

https://github.com/microsoft/STL/blob/852a3085906108045a3951064baaf4952f596e9e/stl/inc/xlocnum#L90

This was a workaround for the lack of if constexpr, and it was intended that _Elem2 should always match _Elem. Yet we instantiate/export (as originally observed in #747):

https://github.com/microsoft/STL/blob/852a3085906108045a3951064baaf4952f596e9e/stl/inc/xloctime#L1029-L1030

This is bogus. If it were ever used, it would reinterpret_cast from wchar_t* to const char*.

Fortunately, it's never used. This was last changed by Microsoft-internal MSVC-PR-84019. Earlier, <xloctime> was working around the lack of if constexpr by providing _Getvals templated on _Elem2 (with a "narrow" definition only) and then providing a non-Standard in-class explicit specialization template<> void _Getvals(wchar_t, const _Locinfo& _Lobj). I managed to fix the non-conformance while preserving the export surface, but that required mentioning this bogus instantiation.

In vNext when we can break binary compatibility, we should eradicate this (presumably as a consequence of eliminating all exported C++ classes from the DLL's interface).

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.

Start with stl/inc/xloctime around lines 175-200 and 1029-1030, then read _Maklocwcs in stl/inc/xlocnum around line 90. This is blocked until the vNext branch permits breaking binary compatibility; done means eradicating the bogus wchar_t instantiation/export.