Update sinon to avoid timeouts

[sebakerckhof]

This PR updates sinon. It's kind of hard to explain why it's important, but I'll give it a try:

My first test was timing out when calling the stub function of this library. I found out that this was happening when I had a lot of test files. My investigation revealed that

• Calling the stub method in this library calls the sinon 4 stub function.
• Sinon 4 creates an error stack ( https://github.com/sinonjs/sinon/blob/v4.1.3/lib/sinon/util/core/wrap-method.js#L110 )
• Meteor uses the source-map-support npm package ( https://github.com/evanw/node-source-map-support ) which will change the error stack to map to the original files.
• Since it's the first time (first test) it needs to do some bookkeeping first, part of this is a quicksort that takes a lot of time if there are a lot of files ( https://github.com/mozilla/source-map/blob/ff05274becc9e6e1295ed60f3ea090d31d843379/lib/source-map-consumer.js#L1077 )

This can be seen in the attached performance profile ( between 1100ms-1250ms)

sourcemaps - CPU-20180531T160228.zip

Sinon 5 no longer creates this stack trace in the wrapMethod function:
https://github.com/sinonjs/sinon/blob/master/lib/sinon/util/core/wrap-method.js#L110

Oh and interestingly enough. The slow piece of code (SourceMapConsumer) that resulted in this timeout is exactly what is being replaced by WASM, which you started working on meteor/meteor#9568 (comment) . So if we can upgrade to source-map v0.7, we can probably also upgrade meteor's source-map-support package and avoid such issues in the first place.

[sebakerckhof]

ping @hwillson

[hwillson]

Sorry for the delay @sebakerckhof - thanks!

[sebakerckhof]

Actually, I missed one deprecation, gonna do a quick follow-up PR.
And in the meantime sinon 6 came out (without breaking changes), but I'll give it a quick test anyway.

[hwillson]

Awesome @sebakerckhof - thanks!

[sebakerckhof]

@hwillson . I opened a new one: #31