KeyChar should be preserved for Ctrl+Letter

[adamsitnik]

This PR restores the .NET 6 behavior for Ctrl+Letter key combinations, which is what Windows does as well.

It does so only when Alt key was not pressed at the same time:

Windows Terminal:

cmd.exe:

fixes #75795

[ghost]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This PR restores the .NET 6 behavior for Ctrl+Letter key combinations, which is what Windows does as well.

fixes #75795

Author:	adamsitnik
Assignees:	-
Labels:	area-System.Console
Milestone:	-

[adamsitnik]

/backport to release/7.0-rc2

[github-actions]

Started backporting to release/7.0-rc2: https://github.com/dotnet/runtime/actions/runs/3085454024

[danmoseley]

Why was this case special? Can we think of any other possible similar special cases (or should we look for any) -- do we have good reason to believe this is the only bug of this sort?

[adamsitnik]

Why was this case special?

When I was implementing the new key parser, I assumed that Ctrl+Letter should be mapped just to given Key=Letter with Modifier=Control because preserving the original key char seemed to have no value, as the key char does not map to an ascii character of given key.

Example: User presses Ctrl+A (no matter if Caps Lock is enabled or not) and the KeyChar is 1. 1 in ASCII is SOH: Start Of Heading.

I assumed it was Linux-specific thing, and just assigned default value to KeyChar. I was wrong, as it turned out that Windows also preserves the KeyChar for Ctrl+Letter combinations. I don't know why and what is the benefit of it.

Can we think of any other possible similar special cases (or should we look for any)

Yes, Ctrl+Alt+Letter and as I wrote in the description, I've ensured that for such cases we are consistent too (for them the KeyChar needs to be assigned to default value).

-- do we have good reason to believe this is the only bug of this sort?

No, because there are plenty of key combinations and since I was the only person who tested it so far, I was testing my own implementation and assumptions, which as we can see turned out to be wrong in some cases.

I am actually happy that PowerShell reported this bug as it means that they have performed objective testing.

Don't forget that we have introduced a new config switch and the users can always switch to .NET 6 parser.