.. contains the assembly contents which can be large .

.. method

.. the updated method becomes callable, instead of `Thread.Sleep`.

… spot in test failures

.. and notification handlers, since they can be modified from different
threads.

Fixes dotnet#69144 .

.. methods, from the tests.

Fixes dotnet#73528 .

… and #debugger-app-ready#

- ChromeProvider starts the browser and then waits for a special string
which indicates that the browser is ready for connections.

- Firefox doesn't emit anything similar, so it waits for `console.log: ready`
message we get from `debugger-driver.html`.
  - but since we wait for this in `FirefoxProvider`, when we start the
  `Inspector` after this, the ready message is already gone, so it will
  never see it.

  - To avoid this, if we change the connection logic to instead
    a. start the browser
    b. wait till we can connect successfully
    c. and then start `Inspector`, then it can still be too late if
    the page starts up, and the message is emitted before the Inspector
    was started.

- A proper fix would be to start the browser but with no url specified.
And once we establish a connection to it, *then* send a command to open
a url.

For now, we'll emit the old message `console.log: ready` too, just for
consumption by the firefox tests. And this can be fixed property in the
future.