Improved error handling with pkg/errors

[anishnaik]

This issue closes #107

Instead of using the default errors or fmt package of golang, we are using pkg/errors.

At a high level, the goals are to (1) capture the execution stack at the origin of a new error, (2) do not override the error stack while moving upstream and (3) add contextual messages wherever necessary.

Here are the new rules when dealing with error handling:

1. If you are handling an err from a third party package (e.g. json.Marshal) then there are two options: You can either (a) use errors.Wrap(msg, err) to wrap the err with an additional message and add a stack trace or (b) use errors.WithStack(err) to just add the stack. Do NOT just return back the error.
2. If you are creating a new error that is specific to medusa then there are two options: You can either (a) use errors.New(msg) for an error that does not need any more parameters or (b) errors.Errorf(msg, args...) for any errors that need parameters for more context.
3. If you are handling an err from a downstream source (either custom error or third-party) then there are three options: You can either (a) just return err because you can assume that the error had a stack attached to it downstream, (b) use errors.WithMessage(err, msg) to add more context to the error with no additional args or (c) errors.WithMessagef(err, msg, args...) to add more context and arguments.

This is the first step towards a more robust error handling solution. The next step in this process is to create a standardized framework for error handling so that we have guidelines to identify when / where to contextualize an error versus just returning it directly.