`#ifdef _CRTBLD` cleanup

We have code in the stl/inc headers that looks like this:

https://github.com/microsoft/STL/blob/ed8150e099f6124c50dd4f002cd2ab8c429a81e3/stl/inc/xtimec.h#L25-L28

_CRTBLD is defined only when building the STL's separately compiled source files in stl/src. (The name is a relic of the era when the CRT and the STL were neighbors in the same repo.) _CRTBLD is never defined for ordinary users.

When something is guarded by #ifdef _CRTBLD, it's being used for "cross-TU" communication within the STL's DLL and static LIB, but isn't currently needed for user code to communicate with the STL's DLL/LIB. (If the declaration is marked _CRTIMP2, _CRTIMP2_PURE, or similar, then it's being DLL-exported and must remain so for binary compatibility, but we don't need to provide a declaration to users.)

In principle, we should be able to cleanly separate all of this #ifdef _CRTBLD code, such that it doesn't appear in stl/inc at all. Sometimes this hasn't been possible because we don't have convenient .hpp files in stl/src that are being included by the necessary TUs, but we could add them. Adding .hpp files to stl/src has minor setup impact in the MSVC-internal repo so they aren't free, but it's not a huge deal. As usual, we always need to follow the "Hack These Files" checklist.

In some cases, a cleanup may be annoying or counterproductive, e.g. we have a guarded time_put<unsigned short, _OutIt> partial specialization. We would prefer PRs to be relatively non-invasive and easy to verify correctness.

Start with the _CRTBLD guards in stl/inc, including the example in stl/inc/xtimec.h, and inspect the corresponding separately compiled sources in stl/src. Identify declarations that can move behind internal .hpp files while preserving exported declarations and avoiding invasive cases; follow the Hack These Files checklist when adding or removing files.