Add an allocation module to the stdlib

[aiverson]

This adds a convenient and powerful API for memory management.

[aiverson]

I don't really know how to test a memory allocator effectively. Advice would be convenient. Additionally, I haven't finished the testing framework yet, so testing is inconvenient.

[capr]

I have a few suggestions, take them for what they are: why don't you just add the code directly and try to build on it as much as you can, that is, try to use these lower level APIs in your higher level ones as much as possible so that every API is actually used somewhere, the more calls to it from different contexts the better. Your usage code might give you better insights into how to shape these APIs than humans can. Any good advice you will get from others will come from the same place anyway, that is, people remembering from the experience of using an API why that API was good or bad, eg. I can tell you that memmove is more useful to me than memcpy simply because I needed overlapping copying in enough contexts to justify having only that variant in the stdlib, or I could tell you that I never needed cond with more than 3 args but I did need a case-like (or sql-coalesce-like if you will) macro once or twice (and that btw I prefer iif instead of cond -- in usage you can see why, lacking that, I'll have to resort to explaining and justifying which is far less effective. But this list of little details is so long that it will take forever to shape the APIs with conversations. I think it's more effective for us to write our apps and try to push down common functionality and data structures and whatnot into libraries and if some of them end up being good enough for other people to use, then maybe they'll have a place in a stdlib and then we'll all drink from the holly grail of code reuse.

Anyway, if you do choose to consider this, some implications follow like keeping it light on the docs (a terse but organized API list might be enough at first eg) -- the more docs you write from the start the less willing you'll be to change the APIs later and throw all that work away. Oh and try to communicate in a less justificative manner (eg. cut down on adjectives like "convenient and powerful API"). Sorry if this sounds like editorializing :)