Re-think Error Design

Axios library returns err.response, err.request and err.config, which are very fat and make stdout impossible to read. Need to figure out if we have to return some of these values to the user or not. And if so, we have to define the output + design.

The v2 JSON API returns this on error:

errors: [{id: ..., help: ...., code: ....,  details:...}]

SDK deserializes these fields into:

{ ValidationError: Validation error, cannot save post.
    at makeRequest.catch (ghost/ghost-sdk/packages/admin-api/lib/index.js:290:33)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  name: 'ValidationError',
  context: 'Validation failed for \'posts[0]\'',
  type: 'ValidationError',
  details:
   [ { keyword: 'required',
       dataPath: '.posts[0]',
       schemaPath: '#/properties/posts/items/required',
       params: [Object],
       message: 'should have required property \'title\'' } ],
  help: null,
  code: null,
  id: '2f5ebe00-3917-11e9-8a93-53537def9b36' }

This is cool. But if you get a library error, the error looks like:

{ Error: connect ECONNREFUSED 127.0.0.1:2368
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1104:14)
  errno: 'ECONNREFUSED',
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 2368 }

Error is different. This is hard to document & hard to work with.
Need to figure out what todo.

Start by reviewing the error examples in the issue and the stack-trace entry point at ghost/ghost-sdk/packages/admin-api/lib/index.js:290. Compare the SDK's API and library error shapes, then define the intended error output and behavior. Done means the error design is documented clearly enough to guide implementation.