One common performance problem we see is that Loggers and their children may
be composed  with one or more With() invocations, but the logger/s is/are
not used in most invocations of the function.

For example, an author might initialise a logger with some function-scoped
contexttual information at the start of a function:

```
l := logger.With(zap.String("tripID", trip.ID))
```

but never use 'l' except in seldom taken branches. However, in the majority
cases the expensive with operation has been performed which can result in the
wasted effort (in terms of alloc, CPU) of cloning (e.g of the JSON encoder).

This commit adds a new method on Logger, WithLazy, which defers all of this
expense until the time of first use. This creates considerable performance
improvement for the cases where a logger is not regularly used.

This does require an explicit opt in, because the author must be aware there
is the possibility of objects living longer than the scope of the method
wherein WithLazy is called. Additionally, cases such as logging objects where
the object is modified between the WithLazy and logging that will reflect
the state of the field at log time, rather than With time, which is something
authors need to be aware of.

```
 % go test -bench=Benchmark5With
goos: darwin
goarch: arm64
pkg: go.uber.org/zap/exp/lazylogger
Benchmark5WithsUsed-10           	  527385	      2390 ns/op
Benchmark5WithsNotUsed-10        	  563468	      2246 ns/op
Benchmark5WithLazysUsed-10       	  475064	      2642 ns/op
Benchmark5WithLazysNotUsed-10    	 2255786	       527.4 ns/op
PASS
```

Furthermore, one core microservice in Uber has seen a reduction of 10% heap
allocation by simply using this feature.

This makes for slightly more readable code.

Excessive detail in var name.

Test and assert behaviour of .With.WithLazy, .WithLazy.WithLazy,
.WithLazy.With combinations.

Split the doc strings into multiple paragraphs, adjust the wording.