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.
