system_error: Map errc::broken_pipe to ERROR_BROKEN_PIPE.

[DaanDeMeyer]

Description

I noticed std::error_code(ERROR_BROKEN_PIPE, std::system_category()) == std::errc::broken_pipe didn't work so I checked the source and found there isn't a mapping for it. This PR adds the missing mapping.

Checklist

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[BillyONeal]

I believe this was the first bug I tried to fix on the VC++ team but there were some ABI concerns (namely, because it changes the behavior of the DLL so programs that get an updated redist might have different behavior). @amyw-msft I vaguely recall the UCRT making a similar change though recently and it worked out OK?

[BillyONeal]

I replicated our old-as-the-hills internal bug about this as #413

[BillyONeal]

Thanks for your contribution!

[StephanTLavavej]

This looks good to me. Although it's a one-line change, we needed to think about it for a while, as it affects the separately compiled msvcp140.dll that can be installed on end user machines and affect the behavior of already-installed programs. Since you and others have noticed this behavior over the years, it seems worth the minimal risk to fix; I have difficulty imagining how a program could be negatively affected by this change.

[BillyONeal]

Thanks for your contribution!