implement io.Copy interfaces: io.ReaderFrom and io.WriterTo

This pull request optimizes use of ~~io.Reader and io.BufferedWriter~~ (edit: the **reader** and **BufferedWriter** types in this package) in io.Copy.

In my opinion it didn't make sense to implement the io.ReaderFrom interface in the non-buffered writer. Since it does not buffer its input the way to actually implement is basically to allocate a BufferedWriter and call its ReadFrom method on each invocation. You would probably see a slowdown (due to larger allocations). The only benefit would be in the compression ratio of the output.

The benchmarks were already using io.Copy, so their performance was improved with these changes (except for benchmarks of the non-buffered writer).

Due to the drastic difference in some benchmarks I was wondering if it would be better to fork the benchmarks, creating one version that exploits the interfaces and one that doesn't. I do think it's important to benchmark with the interface, bypassing buffering/memcpy allows the internals to be more precisely benchmarked and optimized. 

```
benchmark                            old ns/op     new ns/op     delta
BenchmarkWriterManpage               42666         41468         -2.81%
BenchmarkBufferedWriterManpage       60727         48590         -19.99%
BenchmarkWriterJSON                  435931        436059        +0.03%
BenchmarkBufferedWriterJSON          459506        436421        -5.02%
BenchmarkWriterRandom                218363022     218837476     +0.22%
BenchmarkBufferedWriterRandom        213386417     212948048     -0.21%
BenchmarkWriterConstant              15240343      15226202      -0.09%
BenchmarkBufferedWriterConstant      15054163      14622514      -2.87%
BenchmarkReaderManpage               22753         19413         -14.68%
BenchmarkReaderManpage_buffered      22720         19383         -14.69%
BenchmarkReaderJSON                  351204        316192        -9.97%
BenchmarkReaderJSON_buffered         360981        320058        -11.34%
BenchmarkReaderRandom                2795274       1866832       -33.21%
BenchmarkReaderRandom_buffered       2782590       1864450       -33.00%
BenchmarkReaderConstant              16623756      15915651      -4.26%
BenchmarkReaderConstant_buffered     16565261      15890398      -4.07%

benchmark                            old MB/s     new MB/s     speedup
BenchmarkWriterManpage               99.07        101.93       1.03x
BenchmarkBufferedWriterManpage       69.61        86.99        1.25x
BenchmarkWriterJSON                  360.97       360.87       1.00x
BenchmarkBufferedWriterJSON          342.45       360.57       1.05x
BenchmarkWriterRandom                48.02        47.92        1.00x
BenchmarkBufferedWriterRandom        49.14        49.24        1.00x
BenchmarkWriterConstant              688.03       688.67       1.00x
BenchmarkBufferedWriterConstant      696.54       717.10       1.03x
BenchmarkReaderManpage               112.07       131.35       1.17x
BenchmarkReaderManpage_buffered      112.23       131.55       1.17x
BenchmarkReaderJSON                  69.55        77.26        1.11x
BenchmarkReaderJSON_buffered         62.55        70.54        1.13x
BenchmarkReaderRandom                3752.16      5618.25      1.50x
BenchmarkReaderRandom_buffered       3768.81      5624.74      1.49x
BenchmarkReaderConstant              29.82        31.14        1.04x
BenchmarkReaderConstant_buffered     29.80        31.06        1.04x
```
Not sure I understand the problem you see here. Can you elaborate? The underscore is used here because the first of two return values is ignored. It's not `_r` like the other line you commented on.