client has no way to report surprising occurrences

[ctm]

Add a mechanism to allow the client to report surprising things to the server.

Currently the client has 60 warn! invocations that produce warnings on the JavaScript console if something surprising happens in the client. Most of them are things that really shouldn't be able to happen, like we create some flavor of element in the DOM and expect it to be the same type of element later, even though we may receive it via a circuitous route that causes JavaScript to briefly represent it as a more general element (e.g. we create an HtmlInputElement but eventually JavaScript hands it back to us as an HtmlElement. We then ask to cast that Element back into an HtmlInputElement and—in theory—the cast can fail). However, there are also places where the client might detect some sort of state which truly does happen because of a bug (perhaps in the client or in the server). Typically those warnings are super cryptic and would not make sense to an end-user, but they're there so that if the hypothetical occurrence happens to me, I can look in the JavaScript console and see what's going on, or if it happens to someone who I can talk into opening the JavaScript console, I can ask them to do it.

Luckily, these things happen so infrequently that I don't actually recall asking someone else to look in the JavaScript console and I only need to do so myself with new code (typically adding a feature or finishing a chore). However, as we scale up, this practice doesn't scale.

So, as a first step we need a way to have an mb2-specific warn! macro that sends the information somewhere, probably through a regular HTTPS connection and definitely not through the client's WebSocket connections (i.e., so we can report errors with the WebSockets themselves).

There are software-as-a-service providers for this sort of thing; I've used a few different ones back when I was doing a lot of Ruby on Rails programming. I'm marking this easy, because I think it's largely just a matter of researching which ones play nicely under which conditions (rust generating WebAssembly that runs on the browser is different from Ruby on Rails running on a server) and then adding in some configuration files and some Rust boilerplate.

I'm not, however, marking this as high priority because currently we have no cash, nor do we have the volume of traffic to make it worth spending the time researching this. In fact, I've known about this forever; I've only bothered to make a GitHub issue out of it so I can refer to it on the rare connection error issue (#839) that I'm closing.

[ctm]

Oh and for what it's worth, we probably want the server also reporting surprising stuff, because the way I do things now is to scour the server text logs the first thing in the morning and that too is a process that doesn't scale.