Don't set global stack trace limit to be infinite

[jamestalmage]

Infinity depth stack traces hardly seem necessary, but that is what we are currently doing.
#482 fixes that for t.plan(), which I think is important, since t.plan() generates a stack trace whether there is a test failure or not.

My remaining question is whether or not we should shorten them globally. I am not overly concerned about the performance impact of failing assertions, more so other libraries (like bluebird longStackTrace support) that might be creating overly long stacks and slowing things down.

Some investigation is needed here. If an Infinity value does not hurt the speed of a passing test suite, then let's leave it there. Otherwise we should bikeshed on how long it should be.

[novemberborn]

My remaining question is whether or not we should shorten them globally. I am not overly concerned about the performance impact of failing assertions, more so other libraries (like bluebird longStackTrace support) that might be creating overly long stacks and slowing things down.

Changing the stack trace limit may also impact code-under-test. Instead we should set it to Infinity when recording the assertion failure, and then reset it afterwards.

[novemberborn]

We set the limit here:

ava/lib/main.js

Line 25 in dd9e8b2

Error.stackTraceLimit = Infinity;

Instead we should modify the AssertionError constructor to capture an infinite stack trace: https://github.com/avajs/ava/blob/dd9e8b2effe541f9f232ee622452343dac5895dd/lib/assert.js#L31:L54

We need to do the same in the getStack() method: https://github.com/avajs/ava/blob/dd9e8b2effe541f9f232ee622452343dac5895dd/lib/assert.js#L57:L61

We have some existing code for this already: https://github.com/avajs/ava/blob/dd9e8b2effe541f9f232ee622452343dac5895dd/lib/test.js#L24:L31