Fix race condition in VS Code debugger integration tests

[minestarks]

Fixed a race condition in the Q# and OpenQASM debugger integration tests that was causing intermittent test failures.

Problem:

• Tests were racing with VS Code's automatic debugger state requests
• When the debugger paused, both the test code and VS Code would send scopes and variables requests
• Depending on timing, tests could receive responses to VS Code's requests instead of their own
• This resulted in reading variables from the wrong stack frame and assertion failures

Changes:

• Modified test logic: Tests now wait for debugger pause state before making their own requests
• Improved request tracking: Added waitUntilResponse() method to track specific command responses
• Dynamic variable references: Tests now dynamically retrieve variable references from scopes responses instead of using hardcoded values
• Consolidated wait methods: Refactored waitUntilPausedAndAssertStackTrace() and waitUntilPausedAndAssertVariables() into a single waitUntilPaused() method with options
• Enhanced tracker state management: Added proper request-response pair tracking with sequence numbers

The fix ensures tests consistently read variables from the correct stack frame by waiting for their own requests to complete rather than potentially intercepting VS Code's internal debugger communication.

Examples (VS Code's requests in purple, our test's requests in red):

Before, bad run:

VS Code comes in with the variables request, the variablesReference changes from 1003 to 1006, and our request ends up using the wrong id (and the test potentially uses the wron response object too)

Before, good run:

We intercepted VS Code, so the variablesReference 1003 happened to work

Fixed:

We waited until the debugger was paused and VS Code was out of the way, and then sent a scopes request to get the proper variablesReference to call with.

[orpuente-MS]

I am glad you fixed the hard coded variable reference! Thanks!