In Windows host, use WriteConsoleW for stdout and stderr, and locale enabled print for file output

[jtschuster]

Fixes #102174

Per #102174 (comment), this uses WriteConsoleW for writing to stdout and stderr, and the locale enabled _vfwprintf_l for writing to a file.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[jtschuster]

Looks like the tests are failing because WriteConsole fails when stdout or stderr is redirected, so we need to write to a file in that case. Working on the fix.

[jtschuster]

There's a number of other string related functions in the pal that have locale variants, is there any reason not to update those to use UTF-8 everywhere in a follow-up?

[elinor-fung]

Is there a simple test we could add for this?
Maybe something similar to the below, but using DotNetBuilder to set up the install in a directory with characters that don't work properly without the change in this PR:

runtime/src/installer/tests/HostActivation.Tests/DotnetArgValidation.cs

Line 87 in 8b1d06a

public void DotNetInfo_NoSDK()

[elinor-fung]

There's a number of other string related functions in the pal that have locale variants, is there any reason not to update those to use UTF-8 everywhere in a follow-up?

That may depend on the specific function. For example, for things like strcmp, we do just want the ordinal comparison. If we don't need it, I'd rather not have to create/free the locale (for the printing to file/console here, I'm not concerned, since it is not 'normal' app startup - just either explicitly printing info to the terminal or verbose logs enabled).

[elinor-fung]

I believe this PR will also fix dotnet/sdk#17451

[elinor-fung]

Thanks!