Support multiple connections

[dhleong]

In theory we should be able to support multiple connections in a single tabpage thanks to the Buffer/Window distinction, but I'm not sure how well we're actually set up for that.

This feature will probably inevitably require some non-trivial, long-overdue refactoring.

To avoid really obnoxious scripting syntax, we will probably need a separate ScriptEngine instance per connection (to avoid events from one Connection triggering code for another Connection, for example). This sort of suggests a separate JudoCore for each connection as well, but ideally they wouldn't be completely separate. It might be nice, for example, to be able to switch to a different connection's window via scripting, for example.

---

Another approach might be to simply borrow Tintin++'s concept of "sessions." We could introduce a command session(name: String) that sets the current scripting context. Since scripts currently execute only on the main thread (we should provide a primitive for scripting languages to access the main thread in case they want to do threading), having a "current" session/context is not unreasonable. By default, everything executes in the context of the "global Judo session" (gjs) but when you call session(name: String) it creates a copy of the current state (configs, mappings, triggers, etc.) and everything after modifies this copy. Changing Window focus should probably switch to the session that created the Window, and all callback functions should implicitly switch to the session that created them as well.

load() is potentially tricky here. You might expect it to operate on the "current" context, and that would be natural. However if it's used to open a world file, rather than importing some other config script, you would want it to operate in gjs to not be polluted by the current context. It might behoove us to introduce a new function (like include()) that operates on the "current" context, while load() can always operate on gjs.

This approach is tricky, but is actually probably easier to understand than the idea of different Connections somehow having their own ScriptEngine instance that we create at... some point. With this approach, it's very clear when we create a new session, or switch to another: whenever session() is called, which you would just put at the top of existing world scripts if you ever wanted to have multiple connections in one session. For users that only single-play, no change would be necessary.