Trace logs should clearly indicate an error has happened

[Trace - 10:09:25 AM] Received request 'client/registerCapability - (1)'.
Params: [
    {
        "id": "abc",
        "method": "textDocument/formatting",
        "registerOptions": {
            "documentSelector": [
                {
                    "language": "helloworld"
                }
            ]
        }
    }
]


[Trace - 10:16:18 AM] Sending response 'client/registerCapability - (1)'. Processing request took 413323ms

The trace message makes no indication that an error was sent back and I could not figure out why the client/registerCapability was not even being hit. Since the messages were getting logged I knew they were not totally "lost" so I added breakpoints to the vscode-jsonrpc code and realized that VS Code did not like how I had formatted my client/registerCapability request.
https://github.com/microsoft/vscode-languageserver-node/blob/dadd73f7fc283b4d0adb602adadcf4be16ef3a7b/jsonrpc/src/common/connection.ts#L868-L872
We can then later clearly see that message.error is present and bad but the trace message in the console does not include the -32602 error.
https://github.com/microsoft/vscode-languageserver-node/blob/dadd73f7fc283b4d0adb602adadcf4be16ef3a7b/jsonrpc/src/common/connection.ts#L1076-L1098

It seems to me that we should check for more than just message.error && message.error.data. If message.error.code and/or message.error.message is available then we should log those in the trace too.

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32602,
        "message": "Request client/registerCapability defines parameters by name but received parameters by position"
    }
}

Start in jsonrpc/src/common/connection.ts at the linked sections around lines 868-872 and 1076-1098, then follow how response errors are formatted for trace output. Reproduce the client/registerCapability response shown in the issue and verify that available error code and message details appear in the trace.