Reland "[flutter_tools] Fix DTD "Stream already subscribed" error and wait for analysis over DTD in widget preview" - #193658

Description

Relands #192930 (which was reverted in #193637).

What changed since the original PR

• In AnalysisServer, store and cancel the stdout and stderr stream subscriptions in dispose() before closing _analyzingController and _errorsController, and guard _analyzingController.add with !_analyzingController.isClosed in _handleProgress. Previously, $/progress notifications arriving from the language server during or after AnalysisServer.dispose() threw Bad state: Cannot add new events after calling close in widget_preview_scaffold_test.dart.
• In widget_preview_test_helpers.dart, await analysisServer.onExit after analysisServer.dispose() in addTearDown so the analysis server process has fully exited before temporary directory cleanup on Windows.
• Added a hermetic unit test in analyze_continuously_test.dart verifying that AnalysisServer does not throw when $/progress notifications arrive during or after dispose().

Original description

During widget preview startup or file updates:

1. Concurrent calls to retrieve previews or wait for analysis (e.g., initial command startup racing with file watcher events) could concurrently invoke _waitForLspService(), causing duplicate streamListen calls to the Dart Tooling Daemon. DTD throws JSON-RPC error 103 (Stream already subscribed) when a client attempts to subscribe to a stream it is already listening to.
2. WidgetPreviewDtdServices previously considered the Lsp service ready as soon as any Lsp method was registered on DTD (or upon receiving the first ServiceRegistered event for Lsp). Because the analysis server registers its LSP methods sequentially before posting an initialized event on the Lsp stream, calls to Lsp.dart/workspace/analysis/complete or Lsp.dart/workspace/getFlutterWidgetPreviews could race ahead of their registration and fail with -32601 (method not found).
3. When connecting to a pre-existing analysis server over DTD (--dtd-url), LspPreviewDetector.analysisServer is null, causing analysisServer?.waitForAnalysis() calls during startup and file updates to be no-ops.

This change:

• Deduplicates in-flight calls to _waitForLspService() using a shared future (_waitForLspServiceFuture) so concurrent callers await the same LSP registration check instead of issuing duplicate DTD requests.
• Separates lspServiceAvailable (whether an analysis server has begun registering Lsp services on DTD) from _allLspServicesRegistered (whether all required widget preview LSP methods in kRequiredLspServices are registered), and updates _waitForLspServiceHelper() to listen for the initialized event on the Lsp stream before checking getRegisteredServices().
• Consolidates LSP DTD calls into _callLspService() and removes the kMethodNotFound polling loop now that _waitForLspService() ensures all required LSP methods are registered.
• Safely catches and ignores RpcErrorCodes.kStreamAlreadySubscribed on streamListen calls in WidgetPreviewDtdServices (safeStreamListen).
• Adds WidgetPreviewDtdServices.waitForAnalysis() (invoking Lsp.dart/workspace/analysis/complete over DTD), unifies LspPreviewDetector.waitForAnalysis() so widget preview waits for analysis completion on both tool-managed and pre-existing analysis servers, and moves the startup waitForAnalysis() call inside the DTD error-handling try / catch block in WidgetPreviewStartCommand.
• Adds hermetic regression tests covering concurrent/pre-subscribed DTD streams, partial vs. full LSP service registration (Lsp.initialized), and waiting for analysis over DTD.

Fixes #192424

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.