Implement a local dev HTTP/WebSocket server implementation

[lazerwalker]

The way this project currently relies on Azure Functions and Azure SignalR Service makes it difficult to test locally. One fix for this is to make it so that someone can run a local version of the backend.

This is 3 big-picture things:

• Build a HTTP/WebSocket server that pulls in all of our existing server functions. Our existing abstraction layer (so we're not dependent on the Azure Functions API) should make this relatively straight-forward
• In building WebSocket support, reimplement Azure SignalR Service's group functionality for message delivery
• In the client, abstract our our network handling. We currently hardcode that we send data via HTTP requests and receive data via SignalR. This implementation will probably use WebSockets for maybe 90% of all data and HTTP for the rest.

[lazerwalker]

Letting people run the server locally will help a lot. Let's do this.

[lazerwalker]

Moving this outside "do for 2022" for now. It's more annoying than I want it to be because we still need a Firebase app, and having our admin editor removes the crunch on non-coding writers to set up their own instance.

[lazerwalker]

We'll be adding an Azure PubSub implementation that moves us to pure WebSockets. Leaving this as a separate icebox issue to have a local-only / not serverless server.

[lazerwalker]

See #857