#### Brief overview of PR changes/additions
- A DCS/SOS/PM/APC/OSC sequence (`ESC` followed by `P`, `X`, `^`, `_` or
`]`) now ends at the end of the line it started on if the game never
sends a terminator, instead of discarding everything that follows it for
the rest of the session.
- Half of a sequence left over from a dead connection is dropped when
the next one starts, and the 4096-byte cap no longer leaves the parser
stuck with no way out.
- Well-formed sequences are untouched: Sixel images and Kitty graphics
are still swallowed whole, including ones larger than the cap or split
across packets. Their idle-flush carriage returns no longer hide a
String Terminator either.
#### Motivation for adding to Mudlet
One stray escape byte from a game could black out every line it sent
afterwards - across line breaks, `clear()` and a full reconnect - with
only a BEL able to restore output.
#### Other info (issues closed, discussion etc)
Fixes#9757. The `ESC ]` half of this is not a 5.0 regression, it
behaves identically in 4.22.0, so the bound covers the whole
`mGotOSC`/`mGotString` path rather than just the four introducers 5.0
added. Answering the open question in the issue: text lost to the
blackout is missing from the log as well, because it never reaches the
buffer the log is written from -
`logFollowsTheDisplayThroughAnUnterminatedSequence` covers that.
New `TelnetStringSequenceRecoveryTest` - 46 cases over a real TCP socket
via `TelnetServerStub`. With the fix reverted, 24 of them fail.
**Test case:** connect to any game and have it send `PRE<ESC>Ppayload`
followed by a newline and a few more lines. Every line after it must
still be displayed. Repeat with `X`, `^`, `_` and `]`.
