Fix error_category regression with Boost.System

[StephanTLavavej]

Followup to #3139.

Bad kitties jump up on the table where they're not allowed. 😼 Boost.System was a very bad kitty:

https://github.com/boostorg/system/blob/9a6d79b84147854aa919644b56b8553f5a2bedb8/include/boost/system/detail/std_category.hpp#L46-L52

#if defined(_MSC_VER) && defined(_CPPLIB_VER) && _MSC_VER >= 1900 && _MSC_VER < 2000

            // Poking into the protected _Addr member of std::error_category
            // is not a particularly good programming practice, but what can
            // you do

            _Addr = id;

When #3139 fixed error_category's default constructor to be constexpr, it had to change _Addr into a union, breaking this highly non-Standard code in Boost.System. This resulted in widespread breakage in our test team's "Real World Code" suites.

Because Boost is a widely used third-party library, even if we reported this upstream and they were somehow able to avoid doing this, or simply changed their non-Standard code to detect our new error_category and use different non-Standard code, projects throughout the C++ ecosystem would be broken until they updated Boost.

Adjusting the STL's code to continue permitting this non-Standard usage is the least undesirable option here (compared to reverting #3139, refusing to yield, adding an escape hatch, etc.). Notes for these changes:

• This is adding a public operator= to _Addr_storage, but it and _Addr are still protected, so this is not observable to Standard code.
• The operator is constexpr to be "transparent", even though Boost doesn't need this.
• The operator takes uintptr_t also to be transparent, because that's what we store.
• The operator is noexcept to avoid emitting EH enforcement.

While RWC test coverage would be sufficient, I'm adding a bit of test code in order to more quickly detect any maintenance changes that would break this workaround. The test takes unsigned int because that's what Boost is using.

(To be clear, I love Boost and I've used it for 20 years, but accessing internal data members is problematic for precisely this reason! 😹)

[strega-nil-ms]

reluctantly approved 😿

[StephanTLavavej]

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

[vinniefalco]

@StephanTLavavej Thank you very much for this fix

[pdimov]

Should have alerted me about it. :-)