runtime: fix wrapper elision when mid-stack inlining

[randall77]

When we print a stack trace we skip wrapper functions, as they aren't user code so they might confuse users.
We currently make the decision on whether to print a stack frame or not, based on some information about the real frame that's on the stack.
However, once mid-stack inlining is enabled, a single real frame on the stack might represent multiple logical user frames. Some of those might be wrappers, some not.

The current behavior is that if the outermost frame is a wrapper, all the user frames inlined into it are not printed (unless the wrapper function is the first in the stack trace, which is a special case).
If the outermost frame is not a wrapper, all wrapper frames inlined into it are printed.

We really need to base the print/noprint decision on logical frames, not real frames.

CL 147361 has a band-aid fix for a test that fails because of this issue.
When this issue is fixed, remove that band-aid.

[gopherbot]

Change https://golang.org/cl/152537 mentions this issue: cmd/compile,runtime: redo mid-stack inlining tracebacks

[gopherbot]

Change https://golang.org/cl/153477 mentions this issue: runtime: proper panic tracebacks with mid-stack inlining