This is my little Christmas-break experiment trying to (among other things) reduce
the amount of generated code for containers.

THIS CODE WILL CONTAIN BUGS AND IS ONLY PRESENTED AS AN EXAMPLE.

The C++ STL is still an undesirable library for many reasons I have extolled in the
past. But it's also a good library. Demons lie in this here debate and I have no
interest in revisiting it right now.

The goals that I have achieved with this approach are:

* Code generation for my game saves roughly 100k across all EXEs and DLLs, bearing
in mind I only implemented a vector class and the total EXE/DLL size is 1.2MB. Other
types are more complicated and using this approach will save me even more.

* Seamless interaction with a Reflection API is a natural side-effect with an order
of magnitude reduction in generated code. The typical approach is to implement a
container interface that the Reflection API will use and implement for each container
type. This has the downside that ALL container code for ALL types needs to be generated
up-front; the cost is massive. Part of me is wondering how the C++ standards committee
intend to fix this (if indeed they even think it's a problem).

* A big reduction of work for the compiler to perform as the implementation is
completely hidden from clients and not stored in header files. This also allows me to
place all containers in a single header file and reduce the amount of files the compiler
has to request.

* I can place my own STL in a DLL and save considerable generated code.

The big downside to this approach is that the containers will typically be slower than a
template-based solution, particularly for non-POD data types. Storage of POD types will
be close to the performance of the full template approach but still slower.

There are a few libraries out there that explore different approaches to the STL. Some
examples:

* tinystl - https://github.com/mendsley/tinystl
  A clean, minimal implementation of the STL using the typical templates-in-headers approach.
  Generates less code than the STL but only by virtue of offering much less.
* uSTL - https://msharov.github.io/ustl/
  Attempts to minimise generated code through putting all memory operations into untyped buffers.
  Actually gets most of its code-gen benefits from just being a simpler STL (see below).
* RDESTL - https://github.com/msinilo/rdestl
  Not tried this one but worth mentioning as it's aimed at game development.
  Smaller and simpler than the STL with quite a few performance benefits.

What I've found is that, after 20 years of having templates in the language, compilers
are amazing at inlining generated template code and amortising the cost with everything
around it. In my experiments, a uSTL-inspired vector actually generates MORE code these
days and for small executable sizes it was next to impossible to beat the compiler with
any other approach. To summarise:

* If your project is <100k then you will typically have a small amount of container
instantiations and individual function calls. The compiler will do a better job of
generating the smallest amount of code so you might as well stick with a typical basic
template implementation (or just using a C approach).

* If your project is <800k then this tightly tuned approach will give you some good
savings. It's quite brittle to cleanup though (e.g. adding a type traits object) and you
can easily lose generated code gains if you're not careful.

* Anything bigger should see massive savings and afford you the luxury of making the code
cleaner at the expense of some more generated code.