This was broken by golang/go@321c312d8246dec6889f5fe334b6193c320baf0e.

Go 1.8 renamed this function; cf. golang/go@87e48c5.

Necessary because our evil memclr should go away.

Benchmarks:

    benchmark                                          old ns/op     new ns/op     delta
    BenchmarkOutMessageReset/Single_buffer-12          4.94          4.95          +0.20%
    BenchmarkOutMessageReset/Many_buffers-12           10.4          12.0          +15.38%
    BenchmarkOutMessageGrowShrink/Single_buffer-12     42861         47666         +11.21%
    BenchmarkOutMessageGrowShrink/Many_buffers-12      101896        100626        -1.25%

    benchmark                                          old MB/s     new MB/s     speedup
    BenchmarkOutMessageReset/Single_buffer-12          4853.85      4851.64      1.00x
    BenchmarkOutMessageReset/Many_buffers-12           2311.82      2006.72      0.87x
    BenchmarkOutMessageGrowShrink/Single_buffer-12     24464.39     21998.19     0.90x
    BenchmarkOutMessageGrowShrink/Many_buffers-12      10290.60     10420.48     1.01x

Use int where appropriate, fix up documentation, and clarify. Delete the
implementation where it will soon need to change.

In preparation for changing the public API.

At the level of the OutMessage API. In preparation for reworking its
implementation.

For the sake of testing.T.Run.

In preparation for considering a switch away from the evil use of
runtime's internal memclr function.

This should better stress memclr.

I misunderstood what was being zeroed. Only the header is.

There are a few changes to tests and documentation to reflect changes to
osxfuse behavior. All of them should probably be seen as backwards
compatible. The tests now test the osxfuse 3 behavior, and for this
reason we should consider killing osxfuse 2 support after some time.

Closes #18.
Closes #19.

Tested on OS X 10.11.6 (15G1004) with osxfuse 3.5.2.