Navigate the callstack better when creating custom assertions

[krancour]

Closes #11

This adds a new bit of functionality that makes it possible to create test helpers (custom assertions, really) without worrying that the call stack won't be unwound far enough when the source of the assertion failure is displayed.

See addition to examples/simple_test.go for sample usage.

[arschles]

@krancour let me suggest an addition:

• Make frameWrapper exported
• Make the number of frames to traverse configurable on the newly exported FrameWrapper
• Increment by that number of frames here

[krancour]

So I have now amended the commit with the following modifications:

withFrameWrapper(t) now wraps t with a frameWrapper, which now includes a numFrames attribute. If t is a frameWrapper to begin with, .withFrameWrapper(t) returns a new frameWrapper with an incremented numFrames, wrapping the t referenced by the original frameWrapper. In short-- the result is there's never more than one layer of wrapping.

Re: making frameWrapper exported, I can and will if that is what you want, of course, but I'm wondering if you can explain the reasoning? fwiw, withFrameWrapper(t) just returns the exported Tester interface, which afaik is all that any caller should care about. i.e. I'm assuming we don't want people actually coding directly to frameWrapper type.

[arschles]

@krancour IMO the way you have it now is great! I like the fact that one can recursively wrap Testers, which can easily parallels the layout of code-under-test's stack. 👍

[krancour]

Thanks. 😄

[krancour]

@arschles just in case it gets overlooked, I commented on the outdated diff above.

[krancour]

Also, fwiw, CI failures appear unrelated to this change.

[arschles]

@krancour looks like the gimme tool in the CI build for Go 1.6.0 is failing. I've filed #13 to track, but I'll merge this w/o that, since tests pass for Go 1.5.1