Cache js breakpoint ids and reuse them when adding new breakpoints

[iinozemtsev]

Internally, there are two different code paths to trigger hot restart:

1. Via connected debugger, triggering _hotRestart funciton in dwds_vm_client.dart. This codepath removes existing breakpoints and blocks main script execution (by passing pauseIsolatesOnStart into dartHotRestartDwds) until the connected debugger re-adds breakpoints.
2. Via in-app shortcut in injected UI, which just calls dartHotRestartDwds directly. This codepath does not clear breakpoints and does not block main startup.

The second flow with in-app triggered restart is currently doesn't work as intended:

1. Chrome breakpoints aren't cleared, but the attached debugger still gets an isolate start event
2. It tries to set all breakpoints in a new isolate, and sends add breakpoint commands
3. Chrome API returns an error that the breakpoint exists, and the error is propagated back to DAP server, which sends a set breakpoint error notification to an IDE.
4. The IDE thinks that the breakpoint is "unconfirmed", and hides it from the UI completely.

As a result, the user does not see the breakpoint, but it's there, in Chrome debugger state, and the execution stops on it, and there's no way for user to remove it (except for clearing all breakpoints by the restart/reload from an IDE, which clears chrome debugger state).

The CL attempts to fix it by caching chrome breakpoint ids by js locations, so that when the debugger adds a breakpoint resolving to the same js location, it gets back the same js breakpoint id.

• Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.