Preserve the dedicated stack trace object all the way to encoder

[oakad]

Right now, when stack trace is requested (via an annotation on a level enabler or via an explicit field) it is simply formatted into a largish string and treated like a simple string field. However, stack traces these days can be subject to analysis by automatic tooling and otherwise manipulated.

I think it will be beneficial to:

1. Make stacktrace.Stack object publicly visible
2. Modify the explicit Stack field to carry that object and not a string
3. Provide a dedicated exporter method to handle the stacktrace.Stack object. The default encoder can keep using the default formatter, whereupon user provided encoder can do something more advanced

To my opinion, implementing this improvement is easy and seamless for most users. It will also allow for much safer processing of stacks in the log analysis systems as users will have the choice to supply their own encoders which can encode stack traces in analysis friendly way.

[abhinav]

Hey @oakad, thanks for filing this. This is not an unreasonable idea, but we'd need to think on the design end of this more. We can't just swap out the type of the Stack field because that's a breaking change.

There's also an active PR right now (https://github.com/uber-go/zap/pull/1371) to support changing how stack traces are encoded. If we decide to do this, that will also affect that PR.

[oakad]

One may easily argue that stack traces are the most import pieces of info error log messages carry. So any improvement over the present basic encoding will be welcome.