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

I made [a spiritual successor of `github.com/pkg/errors`](https://gitlab.com/tozd/go/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](https://github.com/go-errors/errors):

```
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.)

まず、パッケージで現在使用されている github.com/pkg/errors とスタックトレースへのアクセス箇所を特定します。既存の動作を、提案されている StackTrace() []uintptr インターフェースおよび代替の Callers() []uintptr インターフェースと比較します。異なるパッケージのエラーが github.com/pkg/errors を必要とせずにスタックトレースを公開または保持でき、互換性に関する期待事項が解決されれば完了です。

索引モデルが issue の本文から書いたものです。