Devtunnel port resources can take a long time to move to "Running" state after tunnel is established

The dev tunnels integration currently relies on health checks to determine when the tunnel is active and to retrieve the URLs for the ports on the tunnel. It does this by calling the dev tunnels service via the `devtunnel` CLI, requesting the status of the tunnel, and when received, stores that status on the resource itself. Once the health check is healthy, the port resource's handler for the tunnel resource's `OnResourceReady` event fires, retrieves the status of the tunnel from the resource, and uses it to set the port resource's URL, etc.

While this works, due to the backoff logic in the health checks system, it can take a long time after the tunnel host is successfully launched before the port resources show as "Running" and have their URLs in the dashboard. On my machine I regularly see it take up to 18 seconds.

It was hoped introducing a new `ResourceStarted` event (see #11353) that fires after the resource has started but before it's healthy would help here by allowing the tunnel resources to handle that event and call the tunnel service via the CLI to get the status. Unfortunately this is still racy and the tunnel host can be started (hence the event fired) but a call to the tunnel service can still return a result indicating the tunnel is not currently running.

To improve this experience we likely need to start a retry loop in the `ResourceStarted` event of the of the tunnel resource that calls the tunnel service for the tunnel status with a short delay in between retries (e.g. 1 second), until one of the following conditions occurs:

- the status is returned indicating the tunnel is now running and has the expected port URLs (i.e. the same logic as the health check)
- a max retry count is hit
- the resource is stopped
- the `CancellationToken` passed to the event handler is tripped

Assuming the loop resolves successfully, the tunnel and its port resources could be updated immediately to indicate they're running. If we take this approach I think the health check can be completely removed as it provides little value anymore and will prevent the tunnel resource from appearing healthy until the health check runs successfully once. We could potentially keep it and make the logic a bit more complex such that it tracks invocations for the current resource instance and shortcuts itself if the status is already available on the resource the first time it runs. That way, the initial status could be owned by the resource itself (rather than the health check) but the health check could kick in to provide monitoring after the tunnel host resource is successfully started.