Allocator base class design

The overall design is based on the following key ideas:

• A container’s new method (or any factory function producing a container object) accepts an allocator by reference as an opaque object conforming to the allocator interface. This approach decouples the allocator type from the container type, eliminating the need for a template parameter to support generic allocators. This addresses a notable limitation in the C++ Standard Library, where the allocator template parameter must be specified for every container method—a cumbersome requirement. For further insight into this challenge, refer to the BDE allocator model. BDE allocator model.
• An abstraction of a memory block that has a notion of its allocator and a notion of its size. It can therefore 'free' its own resource when it runs out of scope or it can ask for additional resources when the current resource is too small. All is packed in an economical, single-function interface, ispired by 'lua_Alloc'. See also the allocator API for C.
• Every allocator has an 'owns' method, which enables composable allocators (see Andrei Alexandrescu's talk on composable allocators in C++).