rethink explorer observer

[holic]

I'm not sure how I didn't come across this earlier and I think this all originally worked when developing because I was using 127.0.0.1:{port} hostnames for all services (explorer, MUD app, etc), but...

Due to browser security policies (implemented as "storage partitioning" in Chrome and "ephemeral storage" in Brave), an iframe to explorer.mud.dev embedded in another origin's page does not have access to the same storage or BroadcastChannel mechanisms as a separate tab/window open to explorer.mud.dev - it runs in an isolated environment.

We can postMessage to this iframe and relay to a BroadcastChannel, but other tabs/windows of the same explorer.mud.dev origin never receive them (and no warnings or errors in the console to hint us in that direction...so this took a while to uncover.)

As a lesser alternative, we can still collect data in the observer decorator and, once we have some data, prompt in the UI to "Observe in Explorer", where that button or link would use window.open, forming a parent/child relationship, allowing us to postMessage and use BroadcastChannel to relay to other tabs.

This will mean that you can't just open Explorer in another window/tab and expect it to work - the opener has to be the app sending the txs through the observer. But we can probably do the same BroadcastChannel relay trick on both the app side and on the Explorer side to make sure all Explorer tabs/windows receive txs from across all the tabs/windows of the app.

The big downside is if the Explorer window that has the parent/child opener relatioship is closed, the communication bridge would also be closed, requiring the user to re-open from the app again. I think we can work around this with some regular pings to detect the status/presence of the opener's window and show connected/unconnected states of the observer in both the app and the Explorer.