Add malloc/free functions to std and use them consistently instead of C malloc

[brson]

These malloc/free would be guaranteed to allocate from Rusts heap. This isn't a big deal now but someday we'll have our own allocator and the existing calls to C malloc are going to create "dark" pools of memory that can't be instrumented like other Rust allocations and could potentially lead to other bugs.

@thestinger What do you think?

[thestinger]

I was thinking that we should add back jemalloc, but this time as a submodule (it's even hosted on GitHub now) and without trying to replace malloc/realloc/free with it (by adding a prefix). This would give us the consistent jemalloc debugging API across platforms including heap profiling, zero/junk filling of memory, debugging, leak detection and statistics. It would also force us to fix any bugs where we're mixing malloc/free and our own allocators since it's going to die horribly.

We would be able to leverage the jemalloc-specific API to implement an allocator API like my proposal at rust-lang/rfcs#39. The API could just be marked experimental for now, because it's going to take a while to settle on details like the best way to report a usable size and whether passing a size to free should be optional, mandatory or done in some completely different way.

[flaper87]

This sounds good. If we decide to add jemalloc back as a submodule, we must
be able to build Rust using a stable version of it (just concerned about
packaging).

I'll put more thoughts on this later, I'm AFK ATM.

[thestinger]

Well, I expect that we'll check out the latest stable tag and add an --enable-external-jemalloc switch to configure.