marshal: use passed in byte slice if available.

[Zariel]

We don't aloways need to allocate a new slice to unmarshal into when the
passed in one is available.

name                old time/op    new time/op    delta
UnmarshalVarchar-4     280ns ± 3%      75ns ± 4%  -73.23%  (p=0.000 n=18+19)

name                old alloc/op   new alloc/op   delta
UnmarshalVarchar-4    1.06kB ± 0%    0.03kB ± 0%  -96.97%  (p=0.000 n=20+20)

name                old allocs/op  new allocs/op  delta
UnmarshalVarchar-4      2.00 ± 0%      1.00 ± 0%  -50.00%  (p=0.000 n=20+20)

[Zariel]

cc @Dieterbe

[Dieterbe]

<3 <3 thanks !

context for those who wonder: https://groups.google.com/forum/#!topic/gocql/ng0d9ZyGwSU

[Dieterbe]

perhaps to be safe we should also have a benchmark comparing the case where nil is passed in. might it be slower due to the type assertion in the new code?

(not sure if this is useful or not, i plan to pass in non-nil slices..)

[Zariel]

There shouldn't be any difference any way, it's also not possible to unmarshal into (*[]byte)(nil)

[Dieterbe]

not sure what you mean, we've been passing a nil []byte so far and it works fine, and i imagine many other users do as well.
while we will adopt the optimized the approach, my point is we should still support nil (and probably confirm it doesn't perform worse with the patch applied)

[Zariel]

There isn't any functional change other than it using the passed in slice.

Scanning into

var b []byte
iter.Scan(&b)

still works as the slice is not nil it is empty, a nil pointer to a slice can't be used.