Error serialization logic is faulty

[rekmarks]

Errors are "serialized" using the serializeError function, and this function has considerable issues. We use the internal utility isValidCode which only returns true if this package has a message for that code in its enums. This sucks, because technically any valid integer code is valid. I don't know what I was thinking when I implemented this.

The error serialization should continue to optionally include the stack property, but it should permit any error object (and especially, error code) that is valid per the JSON-RPC 2.0 specification, i.e. any integer number. Only if the original error object does not conform to the following interface should we modify it and replace it with a -32603 error:

type JsonRpcError = {
  code: number, // specifically, any safe integer
  message: string,
  data?: Json,
  stack?: string, // non-standard, but on occasion useful
}

If a value passed to serializeError violates this interface in any way, we should create a new JSON-RPC error as follows, where data.originalError is the original error value if it's valid JSON:

{
  code: -32603,
  message: 'Invalid internal error. See "data.originalError" for original value. Please report this bug.',
  data: { originalError }
}

See #48 and the following screenshot for examples of how the current logic mangles errors: