spinel: Don't rely on unspecified va_list behavior

[darconeous]

@jwhui noticed a problem when he set up the 32-bit-specific travis
build: the Spinel unit test was failing. Further investigation
indicated that the existing code was relying on some undefined
behavior of the 64-bit x86 implementation of va_list.

It turns out that if you pass a va_list by value through a function,
the exact state of the va_list object is undefined after that call
returns and the caller must ONLY call va_end() on the object.

From the C99 standard, section 7.15, bullet 3 on page 249:

The object ap may be passed as an argument to another function; if
that function invokes the va_arg macro with parameter ap, the
value of ap in the calling function is indeterminate and shall be
passed to the va_end macro prior to any further reference to
ap.²¹⁵

And footnote 215 even says:

It is permitted to create a pointer to a va_list and pass that
pointer to another function, in which case the original function may
make further use of the original list after the other function
returns

Sounds great! So we should just pass around a pointer, right?

BZZZT! Turns out that on x86 platforms, va_list is actually
an array, and as you should already know arrays are treated passed by
pointer (instead of by value) when you pass them as function
arguments.

The solution is to put the va_list in a struct, use va_copy() to
initialize it, and then pass that struct around by pointer instead.
This guarantees that we get the behavior we were relying on, at the
expense of an occasional extra call to va_copy().

[darconeous]

Tagging @abtink, because he'll probably get a kick out of this. :P

[abtink]

Very cool! Thanks.

[jwhui]

LGTM 👍