JupyterLite / Pyodide transport (not yet designed against, just not blocked)

[petercorke]

swift/public/js/comms.js's WebSocketTransport class deliberately
exposes a minimal {onOpen, onMessage, onClose, send} interface
specifically so a second transport implementation (postMessage /
BroadcastChannel, for the case where Python runs in-browser via
Pyodide and a real localhost socket server can't exist) could be
added later without touching main.js. See
roboticstoolbox-python/SWIFT-MPL-SPLIT.md's Phase E for the earlier
framing of this same problem ("JupyterLite runs Python in-browser...
localhost Python server assumptions do not hold").

See also this repo's FUTURE-NO-MICROSERVER.md for the broader version
of this problem -- replacing not just the comms channel but also the
/retrieve/ local-filesystem asset passthrough with hosted HTTPS
delivery, with JupyterLite as one of several motivating contexts.

No design work has gone into the actual transport swap or how
SwiftRoute.py's server-thread model would need to change for a
Pyodide context -- this is purely "the seam exists," not "the seam has
been thought through."

[petercorke]

Cross-reference: the broader version of this problem (assets, not just messages) is tracked in #93.