[performance] Store temporary hashers in a pool

[xaionaro]

To reduce Hasher initialization cost in Sum256 and Sum512 it was used a pool to store *Hasher instances.

Result:

name                    old time/op    new time/op    delta
Sum256/blockSize1-8        314ns ± 1%     253ns ± 1%  -19.40%  (p=0.008 n=5+5)
Sum256/blockSize4-8        313ns ± 1%     249ns ± 2%  -20.42%  (p=0.008 n=5+5)
Sum256/blockSize8-8        315ns ± 1%     251ns ± 2%  -20.32%  (p=0.008 n=5+5)
Sum256/blockSize16-8       310ns ± 1%     242ns ± 4%  -21.76%  (p=0.008 n=5+5)
Sum256/blockSize32-8       309ns ± 1%     244ns ± 4%  -21.20%  (p=0.008 n=5+5)
Sum256/blockSize1024-8    2.40µs ± 0%    2.32µs ± 1%   -3.30%  (p=0.008 n=5+5)

name                    old speed      new speed      delta
Sum256/blockSize1-8     3.18MB/s ± 1%  3.95MB/s ± 1%  +23.99%  (p=0.008 n=5+5)
Sum256/blockSize4-8     12.8MB/s ± 1%  16.0MB/s ± 2%  +25.66%  (p=0.008 n=5+5)
Sum256/blockSize8-8     25.4MB/s ± 1%  31.8MB/s ± 2%  +25.37%  (p=0.008 n=5+5)
Sum256/blockSize16-8    51.6MB/s ± 1%  66.0MB/s ± 3%  +27.88%  (p=0.008 n=5+5)
Sum256/blockSize32-8     103MB/s ± 1%   131MB/s ± 4%  +27.00%  (p=0.008 n=5+5)
Sum256/blockSize1024-8   428MB/s ± 0%   442MB/s ± 1%   +3.42%  (p=0.008 n=5+5)

[lukechampine]

Thanks for the PR! I was surprised to see such an improvement, since newHasher isn't doing much work. I suppose it can make a difference for very small inputs, though.

I tried out a few approaches to removing the overhead. Here's what I came up with: https://github.com/lukechampine/blake3/commit/617550f0731f2f5d11175ca09e4dca00570cc7fc

The performance is on-par with using sync.Pool, but the implementation is simpler. I gave you co-author credit on the commit because you inspired me to look for this optimization. :)

[xaionaro]

Thank you!