Supervisor: Option to use native IPC instead of HTTP/WebSockets

[jmcphers]

Positron's kernel supervisor currently communicates over HTTP and WebSockets with Positron. This has the advantage of being well integrated with tooling (codegen tools, testing tools, Workbench, etc.) and being easy to introspect. However, it also has some disadvantages.

1. It can make the supervisor's activity look malicious to heuristic virus scanners. Launching an HTTP server and then starting executables, however harmless, can be misinterpreted as suspicious activity. See Kallichore block by WithSecure Antivirus - Code security HEUR/APC #5533 for an example (although it is worth noting that we cannot be sure it was the HTTP behavior that tripped the heuristic in this case).
2. It makes the supervisor/Positron interface dependent on (and vulnerable to) system level HTTP proxy and configuration issues. See Supervisor: Fails to connect when http_proxy is set #5481 (comment) for an example.
3. Some operating systems will prompt the user to allow kcserver to access the network. That is undesirable since this service should be an internal Positron implementation detail, and also users can't be expected to know what kcserver is or why it wants to use the network.
4. Going through the full HTTP/TCP network stack adds more overhead than other forms of IPC.

Examples of IPC mechanisms we could use:

• Named pipes (i.e. pipes on Unix, named pipes on Windows)
• Domain sockets, like node-ipc