fix: wide string concatenation

[clavin]

Description of Change

In a recent Chromium roll (#40045) we make some changes that were caused by this following revision: Remove Windows-specific wstring variants of StringPrintf() etc..

While the changes we made appear to be correct, we're observing some unicode conversion errors in practice, where the strings we modified are ending up with U+FFFE (the "replacement character") in them, indicating a string encoding conversion issue.

I'm still digging into the specifics of what exactly is going wrong and verifying that this PR is indeed correct, but this PR brings us in line with the changes Chromium made to address these situations: using base::StrCat (and a few base::NumberToWString). (See: multiple revisions attached to Chromium bug 1371963, each starting with Remove usage of wstring StringPrintf():.)

Release Notes

Notes: Fixed default protocol handler behavior on Windows.

[clavin]

Looking into the test failures, they look like they might be relevant.

Edit: I was missing a space in one of the strings that was being generated. I double checked all the format strings to make sure they correspond to the new concatenated format, and it looks right to me.

[clavin]

The WoA CI fail seems unrelated, caused by Windows AV flagging the electron binary on our WoA runner machine. Other Windows platforms are succeeding.

[clavin]

From my testing, this fixes the usage of app.setAsDefaultProtocolClient when the electron binary's path has characters that get incorrectly re-encoded.

[release-clerk]

Release Notes Persisted

Fixed default protocol handler behavior on Windows.

[trop]

I have automatically backported this PR to "29-x-y", please check out #40908

[trop]

I have automatically backported this PR to "28-x-y", please check out #40909