Alternate Freelist Implementation Idea

From #82:

> One way around the whole static problem would be to let the user provide the memory for the metadata themselves. That would also make it easier to use libmemory in a multitasking environment without the need for locks (but of course would require some API changes/additions).

I like this idea, but it does require API changes, probably significant enough that it does not really work in this way as a "malloc". We could make the stock malloc APIs work with a single freelist (probably still requiring a lock in this case), but could provide extended APIs that allow callers to allocate memory against a particular freelist. Then each thread can have its own freelist and memory allocation zone.

This has some beneficial properties:

- no lock needed if each thread provides its own freelist
- you can portion dynamic memory according to each thread's specific needs
- you can see how dynamic memory is being used across threads without any real effort put into analytics development - unlike a single heap case