fix(logging): combine newline-split stdout messages into one log entry

[rishika0212]

Fixes #9557

When debugPrint('line1\nline2') is called, the VM sends the message as two separate stdout events: 'line1\n' and 'line2'. The existing 1ms buffer in StdoutEventHandler only handled the case where the second event is a lone '\n' (e.g. foo followed by \n). It did not handle embedded newlines, so each chunk became a separate log entry
in the Logging screen.

The fix extends the buffer logic: if the buffered message ends with '\n', the next incoming message is treated as a continuation of the same print statement and combined into a single log entry.

_StdoutEventHandler was also exposed as StdoutEventHandler with @visibleForTesting to allow direct unit testing of the handler logic.

Before: debugPrint('line1\nline2') appeared as two separate log entries.
After: It appears as a single log entry.

Pre-launch Checklist

General checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read the [Flutter Style Guide] recently, and have followed its advice.
• I signed the [CLA].
• I updated/added relevant documentation (doc comments with ///).

Issues checklist

• I listed at least one issue that this PR fixes in the description above.
• I listed at least one issue which has the [contributions-welcome] or [good-first-issue] label.
• I did not list at least one issue with the [contributions-welcome] or [good-first-issue] label. I understand this means my PR might take longer to be reviewed.

Tests checklist

• I added new tests to check the change I am making...
• OR there is a reason for not adding tests, which I explained in the PR description.

AI-tooling checklist

• I did not use any AI tooling in creating this PR.
• OR I did use AI tooling, and...
  • I read the [AI contributions guidelines] and agree to follow them.
  • I reviewed all AI-generated code before opening this PR.
  • I understand and am able to discuss the code in this PR.
  • I have verifed the accuracy of any AI-generated text included in the PR description.
  • I commit to verifying the accuracy of any AI-generated code or text that I upload in response to review comments.

Feature-change checklist

• This PR does not change the DevTools UI or behavior and...
  • I added the release-notes-not-required label or left a comment requesting the label be added.
• OR this PR does change the DevTools UI or behavior and...
  • I added an entry to packages/devtools_app/release_notes/NEXT_RELEASE_NOTES.md.
  • I included before/after screenshots and/or a GIF demo of the new UI to my PR description.
  • I ran the DevTools app locally to manually verify my changes.

[srawlins]

Just a preliminary review so we can kick off CI.

[srawlins]

We should do something to avoid the repeated buffer! here. Let's make buffer private, for one thing. But since it's mutable, that probably won't help promotion.

Up above, can we make a local variable from the non-null buffer result? Like

if (buffer case final currentBuffer?) {
  // Here, `currentBuffer` is non-null.
  // Read from `currentBuffer` for new `logData`,
  // and write to `buffer` when writing
  // `buffer = null;`.
}

We might even want to move lines 858-899 into a helper function, as handle() is getting quite long now.

[rishika0212]

Implemented, thanks
Addressed this by making the stdout buffer private and using a promoted local (if (_buffer case final currentBuffer?)) to remove repeated non-null assertions.
Also extracted buffered-event handling into a helper to keep handle() shorter; tests still pass, including newline continuation coverage.