Don't trim bracketed pastes set via OSC52

[lhecker]

• Moves clipboard writing from ControlCore to TerminalPage.
  This requires adding a bunch of event types and logic.
• Store the clipboard counter and compare it during pastes.

Closes microsoft/edit#279

Validation Steps Performed

• Launch Microsoft Edit and copy text with a trailing newline
• Paste it with Ctrl+Shift+V
• It's pasted as it was copied ✅

[j4james]

For the record, this seems wrong to me (assuming I've understood the change correctly). Because trimming carriage returns from the end of a paste is in some ways a security feature, and this is disabling that protection in the one situation where it could be most helpful.

That said, this is already a problem with multiline pastes (see #13014), so it's not any worse than it was before. It just feels like in both of these cases that we're misleading users. We have options to trim trailing whitespace, and warn on multiline paste, and they're labelled as OFF or ON, but they're actually implemented as OFF and MAYBE. Perhaps there's a need for a third option for the more paranoid.

Not that I'm expecting you to solve that now. I just wanted to note my concern.

[lhecker]

But this PR will only skip trimming if the paste is bracketed (the || !bracketedPaste check). Shouldn't shells aware of bracketed paste avoid submitting the input unless the user additionally presses enter (= this PR doesn't make the situation worse)?

[j4james]

Shouldn't shells aware of bracketed paste avoid submitting the input unless the user additionally presses enter

First off, neither the cmd shell nor powershell are aware of bracketed paste. And even in shells that do support bracketed paste, it can be bypassed if the attacker has access to your input (i.e. you've connected to a remote system or application, rather than just viewing a malicious file).

But as I said, this is already an issue, so this PR doesn't make it any worse. It's just another vector that would need to be addressed if we ever did want to fix the problem.