cancel old connection/toolbox instead of preventing new connection

The current code ignores a new connection request if there's an existing request underway. But pending requests can stall for a variety of reasons, so this change reverses the logic, ignoring an existing connection (or destroying its toolbox once it gets created if it's past the point of no return) once a new connection request has been initiated.

With this change, a new request should never be ignored because of a stalled existing request, so it should never be possible to permanently break the Connect button by racing connection requests.

This change doesn't prevent all bustage, of course. If the app can't be installed, or it can't be run, or the toolbox can't open, then the connection attempt will still fail.

It also doesn't completely clean up after a stale request, since a stalled connection can get unstuck when the Simulator starts, whereupon it'll still run the app in question, even if it won't hook up a toolbox to it. But the app will run in the background, so the UX impact will be minimal.

And I don't think it's worth the complexity of figuring out how to prevent this from happening right now with our current callback-based approach to asynchronously running apps, although it's worth thinking about long-term architectural changes that make cancelling a pending "run app" request easier (f.e. using a cancellable promise that either aborts the request or runs a "quit app" function to clean up after itself).