Make it easy to test Fatal logs without requiring indirection at the call site

[prashantv]

Related to #494

There's no clean way to test code that uses Fatal,

Rather than exposing the internal/exit package, we could expose an option that overrides the exit function used by zap.

[abhinav]

The expectation in code that calls log.Fatal is that the line following
log.Fatal will never be executed.

log.Fatal("foo")
panic("not executed")

If we allow users to override the behavior arbitrarily, there's no guarantee
that their logic satisfies this guarantee.

Perhaps a better choice is to allow choosing between pre-defined behaviors.
For example, choosing between exiting the process, panicking, or exiting the
current goroutine.

zap.OnFatal(zap.PanicOnFatal)
zap.OnFatal(zap.ExitProcessOnFatal)
zap.OnFatal(zap.ExitGoroutineOnFatal)
// naming TBD

For ExitGoroutineOnFatal, log.Fatal will call runtime.Goexit(). For
PanicOnFatal, log.Fatal will panic.

This makes testing log.Fatal possible because one could do the following with
PanicOnFatal.

log = log.WithOptions(zap.OnFatal(zap.PanicOnFatal))

var panicked interface{}
func() {
  defer func() {
    panicked = recover()
  }()
  
  log.Fatal("foo")
  t.Error("log.Fatal did not exit")
}()

Or the following with ExitGoroutineOnFatal.

log = log.WithOptions(zap.OnFatal(zap.ExitGoroutineOnFatal))

done := make(chan struct{})
go func() {
  defer close(done)
  
  log.Fatal("foo")
  t.Error("log.Fatal did not exit")
}()
<-done

[prashantv]

That seems reasonable, and would be enough for the test-cases I'm looking at.

There's some cases cases where the test can't easily set up a defer (e.g., in one case, there's a Fatal inside of a time.AfterFunc). However, the test can either use an observer logger and wait till a fatal log is logged, and can even set up a logging hook to be notified.

Looking at the code for how the fatal is plumbed through, I think the pre-defined exit/panic behaviour would be easier to plumb through to the CheckedEntry as well.