Live signals

Just some thoughts..

The signal system currently works by executing an external command, which of course requires a `fork -> exec` chain, resulting in spawning a new process. This works reasonably well from a scripting point of view, but it is quite bad for writing standalone (long running) tools that integrates nicely with yabai. This is because yabai acts as a client invoking a command; to enable inter process communication, the tool integrating with yabai would need to run a server on its own (or have some way to be invoked) to consume the information.

When a signal is registered it should be possible to specify a communication type/kind/class: *exec*, *fifo*, *socket*.
If *fifo*/*socket* is selected data would be passed as json equivalent to the ouput of the query system for that entity, instead of setting an id in an environment variable (as is done for the *exec* type -- the way signals work now).

A system like this would need to be structured differently from the current signal system. It should be possible to listen for multiple event types without having to require one *fifo*/*socket* for every event/signal that is registered, assuming they are all reported to the same client. The client would differentiate by type in its message handler, and handle each event as appropriate.

No files or tests are named. Start by reading the current signal system and the query system output, then compare the existing exec-based flow with the proposed fifo/socket communication and determine how multiple event types would be delivered to one client; done requires an agreed design and implementation scope.

Written by the indexing model from the issue text.