Make notification trait methods async and non-blocking

[ebkalderon]

Changed

• Make all LanguageServer notification trait methods async fn and non-blocking.

This pull request makes all LanguageServer notification methods async fn so that we can .await on client responses inside these method bodies, once we implement proper server-to-client communication later on. Instead of spawning these requests with tokio::spawn(), as we currently do in Printer, we could .await them directly inside these methods without blocking the executor.

This also replaces the internal Delegate::delegate_request() and Delegate::delegate_notification() methods with delegate_request!() and the delegate_notification!() macros, respectively, to avoid the nested .awaits and avoiding lifetime woes caused by the lack of proper async closures in the language. Perhaps once async closures get added to Rust later on, we could re-evaluate whether to replace them with dedicated methods again.

Affects #13.

CC @icsaszar

[ebkalderon]

A hypothetical example of making a server-to-client request inside textDocument/didOpen:

async fn did_open(&self, client: &Client, params: DidOpenTextDocumentParams) {
    match client.apply_edit(WorkspaceEdit::default()).await {
        Ok(true) => info!("edit applied!"),
        Ok(false) => info!("edit was not applied!"),
        Err(err) => error!("client returned a JSON-RPC error"),
    }
}

Note that this will require further work on the Printer (likely to be renamed Client), as mentioned in the PR description.

[ebkalderon]

Feel free to review the changes before I merge at your leisure, @icsaszar!

[icsaszar]

Very nicely done with the macros, this makes things a lot easier to add and maintain methods.