include stack trace when printing error message if a seeder fails

[aaltepet]

I was building seeders for a new project and found that the error message printed did not include enough information (like which file caused the problem). This PR enhances the error message printed in the .catch(function(e) { }) handlers so include the stack trace. As an example, an exception running db:seed:undo now looks like the following, and I can know exactly where the error is.

== 20170110190423-admin-act: reverting =======
Seed file failed with error: Cannot read property 'getProfile' of null TypeError: Cannot read property 'getProfile' of null
at Model. (/usr/src/app/server/db/seeders/20170110190423-admin-act.js:36:24)
at Model.tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/usr/src/app/node_modules/bluebird/js/release/promise.js:510:31)
at Promise._settlePromise (/usr/src/app/node_modules/bluebird/js/release/promise.js:567:18)
at Promise._settlePromise0 (/usr/src/app/node_modules/bluebird/js/release/promise.js:612:10)
at Promise._settlePromises (/usr/src/app/node_modules/bluebird/js/release/promise.js:691:18)
at Async._drainQueue (/usr/src/app/node_modules/bluebird/js/release/async.js:138:16)
at Async._drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:148:10)
at Immediate.Async.drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:17:14)
at runCallback (timers.js:649:20)
at tryOnImmediate (timers.js:622:5)
at processImmediate [as _immediateCallback] (timers.js:594:5)

[mention-bot]

@aaltepet, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Americas, @cusspvz and @gotrevor to be potential reviewers.

[broofa]

Why log just err.message and err.stack rather than the whole error object as I'd proposed in #393?

[sushantdhiman]

@broofa I honestly wasn't aware about your PR and this was just proposed so I merge it, as this was basic fix.

In the end our goal is to display full error stack. Does printing whole error object have any advantage over using message, stack separately

[broofa]

I know it's not uncommon for modules to have custom error classes with additional information. E.g. Joi and Ajv throw validation errors that provide an errors property that provides details about which fields are invalid.

That said, I don't think that field would be included if you do console.log(err) on such objects. So I don't know that there's a practical difference here. I was just curious if there was some reason I wasn't aware of.

I.e. No action needed. :-)