Support narrower-scoped usage of kak-lsp

[Screwtapello]

Currently, at least according to the Linux installation instructions, kak-lsp runs as a system service which seems sub-optimal:

• it takes exclusive ownership of a TCP port on the loopback interface. While TCP ports are fairly plentiful, memorable port-numbers are less so, lots of tools want to use one and it's hard to handle collisions gracefully.
• It's reasonable to have multiple versions of a compiler toolchain installed, and hence multiple LSP servers for a single language. Normally this is easy to handle by setting $PATH appropriately for each project, but since kak-lsp runs as a service it can't see $PATH changes.
• I'm just uneasy about a long-running, unauthenticated service, even one limited to the loopback interface, that will accept file-paths and spit back information about them.

I would be much more comfortable with kak-lsp if it followed a model a little more like Kakoune or tmux:

• kak-lsp requires a session identifier on the command-line; the Kakoune integration script might pick something like $kak_session so every Kakoune session gets its own LSP server.
• kak-lsp connects to a long-running server listening on a Unix domain socket named after the session identifier, or starts such a server if needed
  • the Unix domain socket should be owned by the current user and mode 0600 for security
• the long-running server starts and manages the relevant LSP servers, much as it already does, but since it's launched by kak-lsp it should automatically inherit the appropriate $PATH and other settings
• the long-running server may exit automatically after a certain period of time has elapsed without receiving a query over the socket

Such a scheme should be just as convenient for the end-user as the current system (automatically starting the correct LSP server, automatically restarting after a crash, etc.), but should be more secure.

I understand this would be a big departure from kak-lsp's current architecture, but if you're open to the idea I'm willing to work on the implementation.

[ul]

I totally support this idea. Current model was a deliberate trade-off in favor of easier implementation and installation to test viability of project. Now when it has been proven to be useful to myself and community it's perfect timing to fix design flaws :-) Thank you for raising this issue!

Regarding implementation I hope current code is straightforward enough to impose not many obstacles. Let me know if you encounter something weird and my help would be useful.

[ul]

Closing it for now as base implementation landed to master, let's post related bugs and enhancements as separate issues.