Error Handling about ghost-cli

[acburdine]

With this commit a class was created to handle all i/o for the CLI; however, it still needs to be able to handle errors.

Some thoughts on how the errors need to be handled:

• There are multiple types of errors that need to be handled in a uniform way. The ones I can think of are
  • Node errors (e.g. system-level errors like ENOENT, EPERM, etc.)
  • NPM errors (since we call NPM under the hood, npm's unique error messages need to be parsed and handled in some way
  • CLI-level errors (higher-level errors caused by bad input data, other error states, etc)
• these errors need to be uniform in how they are displayed (e.g. npm's error format and node's are somewhat different, npm outputs an npm-debug.log, etc.) - the error output needs to be as uniform as possible
• the error output needs to have some ability to recognize context (so just handling errors via process.on('uncaughtException') is not the way to go)
  • node has a domain api that shows as deprecated, so using that is probably not the way to go, but it can provide a good starting point.
• error messages need to be as helpful to the end-user as possible, with an easy path to recover from failure
  • e.g. ENOENT would ask the user if they want to create the missing folder (if it's a folder)
  • EPERM - would give the user instructions as to how to fix folder permissions
  • killed (would be thrown by NPM) - happens when npm runs out of memory and is killed by the OS
    • might need to link to a doc on increasing swap space?
  • any others would need to have a link to a troubleshooting doc perhaps?

[acburdine]

This should be made easier by the output refactor in #115, as well as if we switch to yarn (see #112)