Custom allocator support, Figure out STL container reliance, and other considerations

[Capital-Asterisk]

So far, only IntArrayMultiMap has partial support for custom allocators (but uses a few default stl containers on the inside lol).

I'm not much of a fan of using stl containers, but I'm lazy.

This might be a bit extreme, but I'm considering entirely separating the responsibility of allocation out of the HierarchicalBitset and other classes. Most of their functions simply don't allocate memory. Almost all of them can be made std::string_view-like, simply pointing at a region of memory instead of managing their own.

There's a few advantages to this:

• Simplifies the code
• Allows using the class without needing to know their allocator
• More flexibility on how to arrange memory

Earlier versions of C++ heavily abstracts away memory. Getting a bit opinionated here, the need for custom allocators arose from realizing that memory is important. They're designed to support a 'legacy' style of classes being responsible for allocations. It's possible to code in way that uses memory 'normally', which is kind of the point of this library :p

The allocator can still be bundled together in a separate class to provide the same traditional STL-style interface when needed.

[jonesmz]

std::string_view

probably use std::span instead.

I think I'm going to start making noise in OSP this year about moving to C++20. Maybe not right this second, but not terribly far away.