encoding/json: rely on reflect.Value.Grow

The Grow method is generally a more efficient way to grow a slice.
The older approach of using reflect.MakeSlice has to
waste effort zeroing the elements overwritten by the older slice
and has to allocate the slice header on the heap.

Performance:

	name                old time/op    new time/op    delta
	CodeDecoder         2.41ms ± 2%    2.42ms ± 2%    ~
	CodeUnmarshal       3.12ms ± 3%    3.13ms ± 3%    ~
	CodeUnmarshalReuse  2.49ms ± 3%    2.52ms ± 3%    ~

	name                 old alloc/op  new alloc/op   delta
	CodeDecoder         2.00MB ± 1%    1.99MB ± 1%    ~
	CodeUnmarshal       3.05MB ± 0%    2.92MB ± 0%    -4.23%
	CodeUnmarshalReuse  1.68MB ± 0%    1.68MB ± 0%    -0.32%

	name                old allocs/op  new allocs/op  delta
	CodeDecoder         77.1k ± 0%     77.0k ± 0%     -0.09%
	CodeUnmarshal       92.7k ± 0%     91.3k ± 0%     -1.47%
	CodeUnmarshalReuse  77.1k ± 0%     77.0k ± 0%     -0.07%

The Code benchmarks (which are the only ones that uses slices)
are largely unaffected. There is a slight reduction in allocations.

A histogram of slice lengths from the Code testdata is as follows:

	   ≤1: 392
	   ≤2: 256
	   ≤4: 252
	   ≤8: 152
	  ≤16: 126
	  ≤32: 78
	  ≤64: 62
	 ≤128: 46
	 ≤256: 18
	 ≤512: 10
	≤1024: 8

A bulk majority of slice lengths are 8 elements or under.
Use of reflect.Value.Grow performs better for larger slices since
it can avoid the zeroing of memory and has a faster growth rate.
However, Grow grows starting from 1 element,
with a 2x growth rate until some threshold (currently 512),
Starting from 1 ensures better utilization of the heap,
but at the cost of more frequent regrowth early on.

In comparison, the previous logic always started
with a minimum of 4 elements, which leads to a wasted capacity
of 75% for the highly frequent case of a single element slice.
The older code always had a growth rate of 1.5x,
and so wastes less memory for number of elements below 512.

All in all, there are too many factors that hurt or help performance.
Rergardless, the simplicity of favoring reflect.Value.Grow
over manually managing growth rates is a welcome simplification.

Change-Id: I62868a7f112ece3c2da3b4f6bdf74d397110243c
Reviewed-on: https://go-review.googlesource.com/c/go/+/471175


Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>