Long term maintainability

I was poking around the code today to figure out how this project works. There is a very good chance that I am missing some key info or just wrong, but [the best way to get answers is to first be wrong](https://meta.wikimedia.org/wiki/Cunningham%27s_Law) 😊.

### Experimental CDP methods are being used being used
The best solution would be to not use experimental protocol. Stick to the stable methods or use a first party client like puppeteer/chromedriver. This is unlikely to happen though because most of the CDP methods being used are pretty niche and outside the scope of those projects.

It would be nice to know when something breaks though. I'm thinking we could lint the methods used against the current version of the protocol. There are some nice d.ts files in puppeteer and the devtools-protocol repo on github. Even better would be to run the tests against a variety of chrome versions, but the tests seem pretty sparse at the moment.

### Puppeteer-core is being used to launch undefined chrome versions
Puppeteer only supports the version of chromium that it is bundled with. That means when we pick a version of chrome off of the users system, there is no guarantee that puppeteer can control it properly. This project only seems to use puppeteer to launch the browser and obtain a CDP connection. That shields us from most of the incompatibilities between puppeteer and various versions of chrome, but there have been times when old puppeteer can't launch and connect to new chrome, and vice versa.

I'd recommend switching to something that intentionally supports multiple versions of chrome, like lighthouse's [chrome-launcher](https://github.com/GoogleChrome/chrome-launcher). Or maybe just steal the launcher code from puppeteer and bake it in, and then if it ever breaks we can modify it ourselves to support multiple versions.

### Tests
There is a test but it doesn't look to be in use. I can't quite figure out what it does.

I want to have at least 3 sanity tests.
- One that tests that the extension can be launched from vscode. I have no idea how to do this.
- One that drives the current stable chrome and current chrome canary and verifies we can get a screencast and inspect a node.
- One that tests that the UI shows up.

Start by locating the existing test, the Puppeteer launch path, and the experimental CDP methods described in the issue. Define the supported Chrome versions and testing approach first; done would include sanity coverage for VS Code launch, stable and Canary Chrome screencasting and node inspection, and UI rendering.

Written by the indexing model from the issue text.