[protobuf] Fix protoc.exe use the new headers with old DLLs

[FrankXie05]

Fix vcpkg testing MSVC issues.

cmd.exe /C "cd /D D:\buildtrees\gamenetworkingsockets\x64-windows-dbg\src && D:\installed\x64-windows\tools\protobuf\protoc.exe 
--cpp_out D:/buildtrees/gamenetworkingsockets/x64-windows-dbg/src 
-I D:/buildtrees/gamenetworkingsockets/src/687597c3e9-05f1ecc051.clean/src/common D:/buildtrees/gamenetworkingsockets/src/687597c3e9-05f1ecc051.clean/src/common/steamnetworkingsockets_messages_certs.proto"
ninja: build stopped: subcommand failed.

According to the suggestion of Stephan, add compiler option /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR to workaround this issue.

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[Neumann-A]

I don't think this is the right solution. Please explain the problem further.

[FrankXie05]

@BillyONeal Should we show information about our internal testing to users?

[Osyotr]

What new headers? What old DLLs? What does adding this definition fix?

[BillyONeal]

I don't think we should be working around an MSVC++ compiler team infrastructure issue by changing downstream consumers.

[Cheney-W]

Does this mean we need to keep these failures in the result of VCPKG Testing MSVC run until the MSVC++ compiler team infrastructure issue is fixed?

[BillyONeal]

Does this mean we need to keep these failures in the result of VCPKG Testing MSVC run until the MSVC++ compiler team infrastructure issue is fixed?

Yes. Compiler team needs to fix the infrastructure for their tests.

[FrankXie05]

Close this PR due to https://devdiv.visualstudio.com/DevDiv/_git/msvc/pullrequest/494762.

At present, this problem is avoided by modifying the code logic and macro _ENABLE_CONSTEXPR_MUTEX_CONSTRUCTOR.
Unless we actively pass the macro.

And, this behavior will be the default in 17.9 and this issue will be completely resolved.