Support for obtaining a stack trace without requiring github.com/pkg/errors

首先定位 package 当前对 github.com/pkg/errors 的使用以及堆栈跟踪的访问方式。将现有行为与提议的 StackTrace() []uintptr 接口和替代的 Callers() []uintptr 接口进行比较。当不同 package 中的错误无需依赖 github.com/pkg/errors 即可公开或保留堆栈跟踪，并且兼容性预期已得到解决时，即视为完成。

I made a spiritual successor of github.com/pkg/errors some time ago and in it I want to know if an error already contains a stack trace. The goal is that if a large codebase uses different packages for errors, they should work together and not hide existing recorded information, like a stack trace.

One of the issues with github.com/pkg/errors is that its stackTracer interface uses a custom type only exported by github.com/pkg/errors. And it seems this package relays heavily on that and reuses it and even re-exports it.

I would suggest that instead, the following interface is implemented:

type stackTracer interface {
        StackTrace() []uintptr
}

Then, it is easy to obtain a stack trace, use it, format it, and one does not have to depend on a library which created the error.

If you do want to keep using github.com/pkg/errors and re-exporting it and keeping its interface (to prevent a breaking change), I have seen also the following interface being used in this package:

type goErrorsStackTracer interface {
	Callers() []uintptr
}

But given that github.com/pkg/errors is deprecated, then it is probably reasonable to drop its direct use (this package seems to use it for stack formatting as well) and just change the function to StackTrace() []uintptr.

(As I mentioned in #70, you can also use my package as drop-in maintained replacement for github.com/pkg/errors which provides same stack frame formatting features, but does not lock you in into custom types just to access a stack trace.)