Support custom request and notification handlers

[ferdinand-beyer]

This PR allows users to specify custom handler functions instead of the receive-* multi-methods.

The main reason for that is to enable middleware, e.g. to log/time/trace requests, execute them on different threads, etc. Using the :request-handler and :notification-handler options, one could create Ring-style middleware:

(defn wrap-vthread [handler]
  (fn [method context params]
    (p/vthread (handler method context params))))

;; ...

(defmulti receive-request (fn [method _ _] method))

(def server (server/chan-server {:request-handler (wrap-vthread #'receive-request)}))

Avoiding global state in the multi-methods also allows having multiple LSP implementations on the classpath. Not a common use case, but we found ourselves in the situation where we had both clojure-lsp (to use the linter) and our custom LSP on the dev classpath.

Some tests could now be simplified, using :request-handler instead of with-redefs.

[mainej]

Would you update the Receive messages section of the README to describe how to use the custom handlers?

As you do so, would you explain how the custom handlers should deal with requests or notifications that they don't know how to handle?

They have a few options. They can either return :lsp4clj.server/method-not-found, in which case lsp4clj will arrange to log the message and, in the case of requests, reply to the client with a not-found response. Or they can do these tasks themselves.

[ferdinand-beyer]

@mainej -- Done. Will you please review these? You are better with words than I am :)

[mainej]

Looks good! Optional, but it might be nice to include the middleware example in the README.

[ferdinand-beyer]

Added a middleware example to the README and added :response-executor to chan-server's doc-string. Should be ready to merge now.