fix/enhance: inspector/debugging

[threepointone]

The current implementation of how we do inspection/debugging is a bit broken, and not very usable. Some problems -

• We only "log" messages and exceptions in devtools, which means a developer has to open the devtools to see messages and exceptions.
• If we don't open devtools and connect to the opened edge websocket in time, we throw an error and don't retry.
• We don't buffer messages before we open devtools, which means any messages logged before we open devtools are lost.
• Whenever we restart our devserver, we also restart the inspector server, which breaks the connection. We have a dirty hack in place that restarts the devtools page whenever that happens, but that's pretty gross. We should preserve the server instance, and just clear the console.
• We're using my version of devtools (via https://github.com/threepointone/built-devtools). However, we already have a version of devtools that's better suited for the Workers environment (you can see it in action at https://cloudflareworkers.com). It's a fork that has features like the Network tab etc. We're also planning on investing effort and resources into that fork to modernise it. But we can't move to it until we solve the previous restart problem.

Overall the experience kinda sucks, and we should make it better. Here's a list of fixes/enhancements to be done.

• We should log messages and exceptions in the terminal as well. This itself makes wrangler much more useful and usable.
• We should keep retrying to connect to the edge websocket until we open devtools.
• We shouldn't disconnect and restart devtools when the inspectorUrl changes (when the script changes in watch mode). Instead we should keep it open and just clear the console.
• We should buffer all messages until we open devtools, and then flush them at one go, so you can see previously logged messages even if you hadn't opened it in time.
• Once we have these in place, we should use the devtools hosted at https://cloudflareworkers.com (and continue development on that with more features.)

Assigning this to myself because I'm working on these items this week.

[threepointone]

Some followup tasks that I'm logging here and I'l get around to soon -

• Have configuration to choose a port for the inspector
• If the default port is taken, then choose a port that's not already taken
• Log more types of object in logConsoleMessage
• Investigate the unexpected-response event on the websocket and how/why it gets emitted

How to write tests for the inspector logic -

• Spin up a server, let's call it the 'remote' server.
• Make an empty ink app, and use the useInspector hook inside it. Use the newly made server as input to connect to.
• Send some messages that look like console protocol messages via the websocket, verify that they're being rendered in the terminal
• Connect to the server that useInspector has spun up with a websocket. Let's call this the 'local' webscoket.
• Verify that sending a message from the remote server gets reproduced in the local websocket.
• Similarly, verify that sending a message on the local websocket shows up on the remote.
• Shut down the local websocket. Send some more messages from the remote server. Spin up the local websocket again, and verify that no messages were lost.
• Kill the remote server. Start up another remote server. Verify that you can still send messages from the local websocket

[threepointone]

The remaining task on this, to write tests, isn't blocking GA, so I'm going to move this to the non blocking column.

[threepointone]

We should also make the logs in the terminal much nicer, probably coloured (via #590)

[admah]

@threepointone I'm going to close this in an effort to clean up older issues. Thanks for all of your work on it. We are currently working on updating Worker DevTools across the ecosystem, and those changes should be visible shortly. If you have additional ideas related to debugging/inspecting please file them as separate feature requests.