Deno: Refactor inspector server and client

[bartlomieju]

After landing #6901 we're using v8 Inspector to collect coverage.

It uses the same logic as --inspect/--inspect-brk flag which spawns a WS server.

We shouldn't be creating WS server for --coverage so we need to split
inspector from server part.

CC @caspervonb

[caspervonb]

Not entirely sure what approach we want to take here, we could split the inspector into an optional "remote" part.

struct Inspector {
  // Kept as is today
  v8_inspector_client: v8::inspector::V8InspectorClientBase,
  v8_inspector: v8::UniqueRef<v8::inspector::V8Inspector>,

  // This would be the sessions, websocket url, waker, et cetera stuck into a "context" object.
  pub remote: Option<RemoteContext>,

  // A local session for sending messages on the same thread.
  pub session: LocalSession,
}

Alternatively, we just leave the inspector as is (possibly prefix it with Remote) and introduce a second type of inspector dubbed local inspectors with no baggage.

struct LocalInspector {
  v8_inspector_client: v8::inspector::V8InspectorClientBase,
  v8_inspector: v8::UniqueRef<v8::inspector::V8Inspector>,

  // Again, a local session for sending messages on the same thread.
  session: LocalSession,
}

LocalSession in both cases here is just be session/channel pair with a map that resolves to futures, polishing what CoverageCollector has internally.

I'm leaning slightly towards the first as I'm not sure what implications two inspectors on a single isolate would have if any.

Any thoughts, @piscisaureus?

[piscisaureus]

I'd suggest to add an Option<Arc<InspectorServer>> or something, and make sure that InspectorServer stops the server thread in its Drop handler.

[bartlomieju]

Done in #7584 #7577 #7656 and #7718