Improve the capture of unhandled errors from promises

[joeyespo]

After using the code behind #319 for about a week, we ran into a little problem.

Even though it's recommended that Promise.reject passes in an Error instance, not all 3rd-party libraries do. This lead to production errors with [object Object] as the error message, which wasn't very helpful.

This fixes the problem by creating a new error (for the stack trace), if one wasn't provided, and passing the reason object as extra context.

[mattrobenolt]

So I think we should just handle this inside captureException honestly. In raven-node we just do: https://github.com/getsentry/raven-node/blob/master/lib/client.js#L115-L121

I think that'd be acceptable here as well.

[joeyespo]

I tried that originally. You'll still get [object Object] in these cases since some libraries are calling reject with an object.

[joeyespo]

I just simplified this a bit by using captureMessage instead of making a new Error. The stack trace was just Ember's stack trace, so that wasn't really helping anyone by sending it to Sentry afterall.

[joostdevries]

VERY MUCH 👍 on this. One thing I noticed is that the failed promise is actually also propageted to Ember.onerror (at least for my app) so you might need to implement the same logic there.

[mattrobenolt]

I don't have much context about Ember, but since this is isolated to a plugin, it looks fine. I assume someone else will complain if this isn't quite right. :) But seems legit.

[joeyespo]

@mattrobenolt Haha, I'm sure someone will. Such is continuous improvement. Thanks!