Fix onerror handling when the browser passes an exception arg.

[russelldavis]

I haven't had (and may not have for a little while) time to test this much, but the basic idea is:

• Need to check for lastExceptionStack first. If that exists, we always want to do processLastException, which will use the options that were originally passed via Raven.wrap or Raven.context, and clear the vars related to that so they don't get reused on the next call to TraceKit.report.
• Just check ex rather than !isUndefined(ex) since browsers will sometimes pass null (this happens when running example/index.html -- it's this error) and in that case, it makes more sense to fall down to the final else block
• Call notifyHandlers directly rather than report. The latter does a bunch of stuff we don't want/need here (including the 2000ms timeout thing). I think this means we can get rid of the rethrow arg on report as well (I think this was the only thing using it).

Would also be nice to add some tests that exercise the code path where onerror is called with the exception arg.

[russelldavis]

Note that the current symptom of this is that in browsers where the exception arg is passed to window.onerror, Raven's handleStackInfo function gets called twice for every exception. I think this will normally result in two requests getting made to sentry, but haven't tested yet outside of example/index.html, and in that case, the second error never gets sent because the exception arg gets passed as null (see http://stackoverflow.com/questions/5913978/cryptic-script-error-reported-in-javascript-in-chrome-and-firefox). This ends up getting filtered out in processException due to message being null.

[russelldavis]

(you'll probably want to set breakpoints in tracekit's onerror function to get a feel for what's happening here)

[mattrobenolt]

Awesome, looks sane to me!