stack backtrace: fix skipping

[pohly]

The full backtrace included one entry too many. This only mattered
when that entry wasn't in Ginkgo itself, because otherwise pruning
removed it.

[pohly]

@blgm: so the full stack backtrace was off by one in Ginkgo after all and #590 didn't fix it completely.

This now really cannot be tested in a Ginkgo unit test. The bug is in how codelocation.New calls PruneStack. Because the incorrectly included stack entry will match the /ginkgo/ file pattern, it will be removed before a unit test can check the result.

In the previous PR I was working around that limitation by calling PruneStack directly, but that can only test PruneStack, not New.

The failure can be seen in this Kubernetes unit test:

• check out Ginkgo update + stack fix kubernetes/kubernetes#82176
• run go test -v -count=1 ./test/e2e/framework/log

• Failure [0.003 seconds]
log
/nvme/gopath/src/k8s.io/kubernetes/test/e2e/framework/log/logger_test.go:40
  error [It]
  /nvme/gopath/src/k8s.io/kubernetes/test/e2e/framework/log/logger_test.go:52

  Aug 30 16:31:44.877: hard-coded error
  Unexpected error:
      <*errors.errorString | 0xc000219bc0>: {
          s: "an error with a long, useless description",
      }
      an error with a long, useless description
  occurred

  /nvme/gopath/src/k8s.io/kubernetes/test/e2e/framework/log/logger_test.go:54

  Full Stack Trace
  k8s.io/kubernetes/test/e2e/framework.ExpectNoError(...)
  	/nvme/gopath/src/k8s.io/kubernetes/test/e2e/framework/util.go:1350
  ...

This ExpectNoError function in util.go should have been skipped. Note that the source location in logger_test.go:54 is correct, only the stacktrace isn't.

[blgm]

Thank you @pohly. Here's a new release: https://github.com/onsi/ginkgo/releases/tag/v1.10.1