Re-use the hashtable.

This is a re-base of https://github.com/golang/snappy/pull/23

Just using a sync.Pool by itself didn't seem to affect the numbers much.
Previously, the table was stack-allocated and not heap-allocated, so using a
sync.Pool isn't saving a malloc and GC.

The point of re-using the hashtable, via a sync.Pool, is that you can avoid
zero-initializing it. However, the benchmarks are mixed: some are better, some
are worse. I think that the net result is actually worse, but this commit is
provided to aid discussion of that PR and other changes such as
https://go-review.googlesource.com/#/c/21021/ in the standard library.

benchmark                     old MB/s     new MB/s     speedup
BenchmarkWordsEncode1e1-4     466.23       177.91       0.38x
BenchmarkWordsEncode1e2-4     60.08        191.31       3.18x
BenchmarkWordsEncode1e3-4     174.56       215.35       1.23x
BenchmarkWordsEncode1e4-4     172.29       166.81       0.97x
BenchmarkWordsEncode1e5-4     134.37       127.43       0.95x
BenchmarkWordsEncode1e6-4     152.59       148.35       0.97x
BenchmarkRandomEncode-4       6826.46      7249.27      1.06x
Benchmark_ZFlat0-4            310.41       299.86       0.97x
Benchmark_ZFlat1-4            198.37       165.81       0.84x
Benchmark_ZFlat2-4            8046.09      9300.88      1.16x
Benchmark_ZFlat3-4            123.41       245.15       1.99x
Benchmark_ZFlat4-4            2200.95      2346.55      1.07x
Benchmark_ZFlat5-4            307.16       294.54       0.96x
Benchmark_ZFlat6-4            136.35       130.99       0.96x
Benchmark_ZFlat7-4            130.63       125.27       0.96x
Benchmark_ZFlat8-4            143.56       137.13       0.96x
Benchmark_ZFlat9-4            125.47       120.34       0.96x
Benchmark_ZFlat10-4           365.85       348.07       0.95x
Benchmark_ZFlat11-4           200.01       194.52       0.97x

• encode.go[diff]