Stl: Use [[no_unique_address]] after Clang supports it on Windows

[StephanTLavavej]

VS 2019 16.9 will support [[no_unique_address]]. Clang lists this as supported in Clang 9. However, we suspect that it is not yet supported when Clang targets Windows, because MSVC didn't support it. So, #1363 is commenting out all of our [[no_unique_address]] usage.

• [X] Confirm whether Clang supports [[no_unique_address]] on Windows. (Clang does not.)
• [ ] If it does, proceed to the next step, otherwise we should file an LLVM bug requesting such support, then wait for it to be implemented and available in the version of Clang that ships with VS.
• [ ] Finally, we should begin using [[no_unique_address]] for C++20-only code.

[CaseyCarter]

VS 2019 16.9 will support [[no_unique_address]]. Clang lists this as supported in Clang 9. However, we suspect that it is not yet supported when Clang targets Windows, because MSVC didn't support it. So, #1363 is commenting out all of our [[no_unique_address]] usage.

• [ ] Confirm whether Clang supports [[no_unique_address]] on Windows.

When targeting MSABI Clang emits unknown attribute warnings for [[no_unique_address]]. This is peculiar given that the exact same binary with a different --target triple may understand the attribute just fine. I assume it was the simplest way to have the attribute do nothing until MSVC implements behavior for clang to mimic ensuring ABI compatibility.

• [ ] If it does, proceed to the next step, otherwise we should file an LLVM bug requesting such support, then wait for it to be implemented and available in the version of Clang that ships with VS.

I would guess that work on this will be blocked on access to an MSVC that implements [[no_unique_address]] for validation.

[AlexGuteniev]

I recall first reinventing and then reusing existent compressed pair for barrier callback.
Just a reminder that at least C++20 uses of compressed pairs can be eliminated after this arrives.