Implement formatter<vector<bool>::reference>

[frederick-vs-ja]

Towards #2919.

This PR contains 3 parts:

1. Addressing review comments from @CaseyCarter in the previous PR Implement formattable, range_format, and format_kind #4116.
2. Splitting a small part of <format> needed for the definition of std::formatter (but not its critical member functions) to a new internal header <__msvc_formatter.hpp>.
   1. I believe <vector>, which is one of the most frequently used headers of STL, shouldn't include the whole <format>.
   2. Per [formatter.requirements], IIUC the parse and format functions are only required to be usable if basic_format_parse_context and basic_format_context are available respectively, which is only guaranteed by including <format>. So, I think it's safe to separate their definitions into <format>.
   3. The inclusion in <thread> is reduced as only _UIntegral_to_buff is necessary.
   4. <stacktrace> is currently unchanged because it contains non-template parse member function of a full specialization. Perhaps we can optimize it later.
3. Implementation of formatter<vector<bool, Alloc>::reference> and test coverage for it.

MSVC-internal changes are needed for the new header <__msvc_formatter.hpp>.

[StephanTLavavej]

I pushed a conflict-free merge with main followed by:

• Use TYPED_LITERAL as @JMazurkiewicz suggested.
• Pre-existing: _Fill_align_and_width_formatter::parse => _Parse. This member function isn't exposed to users via inheritance, so it should be ugly, like _Format already is.
• Pre-existing: <stacktrace> should guard #include <format> with __cpp_lib_concepts.
  • Its usage below is already guarded.
• Undo attempted throughput improvement by moving _Fill_align_and_width_MEOW back to <format>.
  • I believe we could get this to work by using the same technique as the following commit, but this PR is already doing a lot - we shouldn't add major drive-by throughput improvements. (The <string> inclusion improvement is already enough.)
• Work around VSO-1236041 (header units bug).
  • The compiler bug specifically affects member functions (including but not limited to constructors) being declared in one header and defined in another. The STL has historically avoided that, which is why it doesn't usually impact us. My workaround is to declare non-member functions to do the work, which is fairly easy because we only have to pass one data member.

[StephanTLavavej]

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

[StephanTLavavej]

Thanks for formatting part of everyone's favorite data structure! 😹 👻 🎉