Running various applications that use jsonrpc2 with the Go race detector shows that there is a race condition where `WriteObject` can be called from concurrent goroutines (e.g., 1 sending a request, 1 writing a response).
This makes the MarshalJSON/UnmarshalJSON methods centralize the logic, instead of requiring callers to occasionally munge responses to make them valid to later JSON-marshal.
Previously, we incorrectly interpreted these as neither a request nor a response, and we printed an error for them. This is incorrect behavior per JSON-RPC 2.0 spec; responses can have a null result.
simplify API by using interface{}, rename from transport -> stream
add WebSocket transport in websocket subpackage
do not buffer in ReadObject, rename GetObjectReader/ReadObject -> NextObjectReader
use xtest (jsonrpc2_test) package to allow us to test subpackages that depend on us (in a future change)
factor out vscode-specific transport code and allow pluggable transports
remove Server (unused) and Serve (unnecessary):
The Serve func had nothing specific to JSON-RPC; it was just a loop
around (net.Listener).Accept. It added no value.
Audited all calls for Printf. Noticed the following in some logs
```
jsonrpc2 handler: sending response {1 %!d(string=) %!d(bool=false)}: jsonrpc2: connection is closed
```
I accidentally made this change in the main repo, instead of here.
This ensures that the server can tell the difference between a response and a request. The old method (resp == nil) didn't work because we use interfaces here, and the interfaces would often have types, but not values.
