Generate `Request` and `Notification` types/methods

[paracycle]

Since the meta model that encodes the spec has a full specification for requests and notifications, we can start generating classes and/or methods for those as well. Currently, the SDK is not able to automatically process request JSON into the correct interface type that is appropriate for the request that is being handled. If we start generating request/notification artifacts, we can automate that for the users of the library as well.

For example, the spec codifies that:

{
  "notifications": [
    // ...
    {
      "method": "textDocument/didOpen",
      "params": {
        "kind": "reference",
        "name": "DidOpenTextDocumentParams"
      },
      "registrationOptions": {
        "kind": "reference",
        "name": "TextDocumentRegistrationOptions"
      },
      "documentation": "The document open notification is sent from the client to the server to signal\nnewly opened text documents. The document's truth is now managed by the client\nand the server must not try to read the document's truth using the document's\nuri. Open in this sense means it is managed by the client. It doesn't necessarily\nmean that its content is presented in an editor. An open notification must not\nbe sent more than once without a corresponding close notification send before.\nThis means open and close notification must be balanced and the max open count\nis one."
    },
    // ...
  ]
}

which should enable the user of the library to handle textDocument/didOpen with a argument of reference that is an instance of DidOpenTextDocumentParams.