Window defensiveness

[LewisJEllis]

This makes us defensive against window not existing so we can work in webworkers. Should fix #784 and #747, though there are some things to figure out/change before merging.

The reason for big 4-branch _window thing is that in web workers, self is a sort-of-global-object-thing, and in Node global is the global object (not that we need raven-js to work in node, but I was testing a few things with it as an easy env that doesn't have window). If none of them exist, I fall back to an empty object rather than doing something like Function('return this')() (CSP issues) or (function () { return this; })() (strict mode issues); I'm pretty sure all of our uses of _window still turn out okay in that case, but we won't properly instrument setTimeout and setInterval. I'm not too worried about that case, though.

I'm not sure what the best approach is gonna be to making tracekit not blow up here; obviously we don't just wanna hand edit it to be defensive every time we update our vendor copy of tracekit (like I've done in this PR just to prove things work). I don't think we can pull off any sort of slick trick where we just make the window reference TraceKit uses actually be something we provide like our _window. Not sure if it makes sense for us to send them a PR to make it defensive, but I guess the webworker use case could be motivating; it looks like the current code at https://github.com/csnover/TraceKit touches window a lot more than our current version, though, and I'm not really familiar with our usage of it/interest in updating.

/cc @MaxBittker @benvinegar

[mattrobenolt]

The copy of TraceKit we have vendored in is already highly modified and we never can just outright update it from upstream. We hand patch in things that we care about when relevant, but we've torn out most of it to make it slimmer and better for us, so I'm not personally concerned with upstream compatibility.

[benvinegar]

Looks good, just one request. Add a comment that links to this PR so that future developers / contributors understand why we're doing this. (Sure, there's git blame, but given enough thrash that could become useless.)

[LewisJEllis]

Sure, done. Just to confirm, we're fine with making changes to our vendored copy of TraceKit in this way? Don't know the background on that beyond what Matt described, but sounds like it should be okay.

[benvinegar]

Sure, done. Just to confirm, we're fine with making changes to our vendored copy of TraceKit in this way? Don't know the background on that beyond what Matt described, but sounds like it should be okay.

Matt is 100% correct. The code is barely recognizable as TraceKit anymore (which is why we imported their entire test suite).