<xmemory>: Investigate constexpr approach between _Default_allocator_traits::allocate and _Allocate

In GH-1369, we will be implementing is_constant_evaluated() pathways in both _Default_allocator_traits::allocate and the global _Allocate function that is called from that function if not evaluated in a constexpr context.

_Default_allocator_traits::allocate
https://github.com/microsoft/STL/blob/ac4fde764ae716512bdd67e0e9577bd53947bc3d/stl/inc/xmemory#L661-L673

_Allocate:
https://github.com/microsoft/STL/blob/ac4fde764ae716512bdd67e0e9577bd53947bc3d/stl/inc/xmemory#L173-L198

Currently, MSVC cannot handle calling the _Allocate function from a constexpr context (_Allocate calls ::operator new which MSVC does not allow in a constexpr function, though Clang does if it is reached transitively from an evaluation of std::allocator::allocate), which is why there is the is_constant_evaluated() block in _Default_allocator_traits::allocate that instead dispatches to std::allocator::allocate (which is permitted by MSVC). Note that _Normal_allocator_traits is not affected by this issue because it does not attempt the optimization at directly calling _Allocate and instead always goes through _Alloc::allocate.

It seems like we should either (1) have _Allocate be completely constexpr-safe (have valid constexpr pathways for all supported compilers), or (2) have _Allocate be a completely non-constexpr function that is just never called in constexpr pathways (and in this case, I believe we could also remove the constexpr pathways in _Default_allocate_traits used in _Allocate, _Deallocate). This depends on whether MSVC will permit the call to _Allocate in the future as the constexpr dynamic allocation implementation matures (in this case, we could adopt approach (1)). Otherwise, we can look into option (2). Regardless, we should pick one of these options to avoid this code duplication and the logic being split up in this way.

Internal Microsoft link only: You can hear more discussion about this issue here: https://msit.microsoftstream.com/video/4740a1ff-0400-b9eb-093e-f1eb3b56cd9a?st=2877

Start with stl/inc/xmemory at _Default_allocator_traits::allocate and _Allocate, then review GH-1369 for the planned is_constant_evaluated() paths and the compiler constraints described here. Investigate the constexpr behavior across supported compilers and document or implement one consistent approach that removes the duplicated split logic.