Experiment with more 'native' binding to JsonRpc

[baronfel]

I've been thinking about this for a while, and issues like #35 have hammered home that this library is hiding too much of the underlying transport from users. I think we would have a lot more room to operate/fix problems without needing new versions of this library if it became more pluggable. To that end, I'm proposing a breaking set of changes that I think would reduce the size and maintenance burden of this library while still making it easy for others to build on top of it.

The primary changes are

• moving to explicitly matching names for LSP requests and notifications (to make RPC binding easier)
• changing return types to be Task-based for requests and EventHandler-based for notifications (again to make binding more seamless for the underlying JsonRpc library)
• adding in Progress<T> and CancellationToken parameters for the members
• changing the 'startup' helper methods to be more of a three-phase operation:
  • pass in some bare minimum set of data (stdin, stdout, server/client implementations) and we give you back JsonRpc instance(s) that are configured for communication
  • you can then customize the JsonRpc instance(s) however you like - this library can provide helpers here for common tasks like logging, etc
  • you can then pass the JsonRpc instance(s) into a helper here that starts them and provides an awaitable hook for you to bind

I think this will reduce a lot of conceptual friction, and make contributing new fixes to this library even easier.