Improved, configurable buffer pools

[nsmith5]

Problem

As discussed in #86 and #85, the current buffer pool leads to heap allocations that are 64 * the largest template rendered. This wastes memory. We cannot simply remove the buffer pool though because it is needed to check template errors before writing HTTP status codes.

Solution

Add a sized buffer pool implementation that garbage collects buffers that grow past a certain point. Use this sized buffer pool by default with some heuristically choosen defaults (I've selected 32 buffers of size 512KiB), but allow users to specify their own if needed. A GenericBufferPool interface has been added that allows users to not only modify the SizedBufferPool and BufferPool implementations, but to implement their own if need be.

Results

Two benchmarks have been added: BenchmarkBigHTMLBuffers and BenchmarkSmallHTMLBuffers where the buffer pool buffers are larger and smaller than the rendered template respectively. As expected, the small buffers lead to more allocations and slower HTML templating than the larger buffers.

Upon inspecting the memory profiles for each benchmark we see the difference in allocation is precisely where we think it should be: buffers are being allocated upon return to the pool because they've out grown our size limit

Buffer larger than templates

Buffer smaller than templates

[unrolled]

This is awesome! Just one tiny comment to fix up. Thanks for tackling this issue 👍

[nsmith5]

Which comment @unrolled? I didn't see any comments on the PR just yet.

[unrolled]

Thanks!!