Description of the new feature/enhancement

If I've enabled VT input mode, I expect to get back a simple stream of characters representing the VT sequences for each key press. If using ReadConsoleInput, then I'd expect a single key event for each character in the sequence, with no virtual key code, and with the character values in the UnicodeChar field.

However, what I get now is a weird mix of the original keyboard events, interspersed with the VT sequence characters. For example, if I press Ctrl+A, I expect to get a single event like this:

But what I actually get is this:

If I enter a character consisting of a surrogate pair, e.g. entering 😛 from the Win+. emoji picker, I get both up and down events for the two surrogate pairs, but the up event arrives before the down event for the first code point!

And note that I also get the up event for the . key from triggering the emoji picker. All I expected to see were the two down events representing the emoji glyph:

This all stems from the fact that we return an "unhandled" state from the TerminalInput::HandleKey method for key-up events, as well as key-down events that don't map to a VT sequence, and those events then get injected back into the input queue. I think it would be better if we just returned an empty string for those cases. That way the only key events that end up in the queue are the actual VT characters.

Proposed technical implementation details (optional)

As explained above, we should only return MakeUnhandled() if we receive something that isn't a KEY_EVENT. Otherwise we should return a blank string, i.e. MakeOutput({}), for any key events that aren't handled.