Support v2 account API error shapes

[ecooper]

Problem

In the future, v2 endpoints of the account API will have a different API shape than the current v1 shape.

v1:

{
  code: string,
  reason: string,
}

v2:

{
  error: {
    code: string,
    message: string,
    metadata: Record<string, any>
  }
}

(excuse the TS types, 🤣 )

Both API endpoints versions will need to be supported.

Solution

The existing parseResponse function already handles translating Account API errors to a catchable error in the CLI. By adding a new helper, parseErrorResponse, we can normalize the error shape before building the error.

Result

v1 and v2 error shapes are supported transparently for the consuming code.

Testing

Updated parseResponse tests to demonstrate normalizing and a few other small changes.