Adopt remapping of error object in structured (json) log message

In pino@7, the error object in a fatal message is now stored on the err key of a structured log message.

{
  "level": "fatal",
  "msg": "Incorrect type",
  "err": {
    "type": "TypeError",
    "stack": "TypeError: Incorrect type\n  at functionName (/path/to/script.js)\n...",
    "message": "Incorrect type"
  }
}

For now, we have added a workaround to move it back to the root of the message (which also ensures we get the same pretty output).

{
  "level": "fatal",
  "msg": "Incorrect type",
  "type": "Error",
  "stack": "TypeError: Incorrect type\n  at functionName (/path/to/script.js)\n..."
}

Should we instead store the error object on the err key? Or should we continue to flatten it into the message object with the type "Error"?

The benefit of storing it on the err key is that the actual error type can be stored on its type key. When processing the messages, it's also easier to check for the err key instead of the value of the top-level type key. It would also mean our messages are consistent with the structured log messages produced by pino. And there is no confusion with other keys that the message may contain, such as stack. The drawback is that it a) introduces nesting and b) requires extra processing to avoid duplicating the error message (since it's also on the error object).

It seems better to not go against the grain and adopt use of the err property*. Regardless of what we decide, I think we need to make this decision before the 3.0.0 release.

* We still have to flatten it when the format is pretty so that the pretty output appears correctly.