Feature: pool allocator

[liss-h]

Adds a pool/arena allocator with a number of arenas for different allocation sizes (number and allocation sizes determined at compile time)

[nkaralis]

Thank you for the PR. I have some questions and comments.

[nkaralis]

Could the allocator create its own pool (instead of relying on one to be constructed)?

[liss-h]

It could use a shared_ptr but it cannot exclusively own the pool, we need multiple allocator instances (of different types, e.g. pool_allocator<int> pool_allocator<long>) to allocate in the same pool.

This is for std container purposes and our own usecase of allocating multiple different node types.

I was pondering if this makes sense but ultimately decided to use a similar design to what metall uses.

I'm still somewhat unsure as the shared_ptr design would indeed be more convenient to use.

[liss-h]

I was basing this design on metall, but I guess they are only doing it this way because they are working with persistent memory. So maybe the shared ptr design makes more sense afterall

[liss-h]

@bigerl opinion?

Pros of current design: best perf (although a refcount increase per copy is really not that expensive)
Cons of current design: easy UB source, inconvenient to use (you always need to take care to keep the pool alive)