[WIP] Custom memory allocation

I think I finally cracked the nut on custom memory allocation.  Back in the ~0.3 versions, libcork had custom memory allocation, but it was very invasive: you had to pass around lots of `cork_alloc` pointers all over the place.  I dropped custom allocators to make the memory allocation API much cleaner (and much closer to the standard `malloc` family of functions).

This patch adds back in the ability to customize the details of how memory is allocated, but without requiring lots of allocator pointers — and most importantly, in a way that lets different sections of the program have *different* custom allocators.  The key is the `cork_current_allocator` macro, and in how all of the allocation functions are defined static in a header file.  That allows different source files to provide different values for `cork_current_allocator`, which their copy of the static allocation functions will use.

There are two breaking changes.  The first is that you must now use `cork_free`, `cork_cfree`, or `cork_delete` to free memory that you've allocated, instead of the standard `free` function.  The second is that you must keep track of how large each allocation is, and pass that in to whichever free function you use.
The big comment at the start of this section talks about this a bit, and I'm going to expand on it in the docs.  You can override which allocator libcork uses to create and destroy objects — i.e., any malloc/free-style calls in libcork.so.  libcork's current allocator is in `cork_allocator`, and you can update that by calling `cork_set_allocator`.  Those two are specific to libcork.

Other libraries that use libcork can *also* allow their users to provide a custom allocator.  They would define their own equivalents of `cork_allocator` and `cork_set_allocator` — for example, `clog_allocator` and `clog_set_allocator`.  That part is opt-in; if a library chooses not to do that, they'll use the same allocator as libcork itself, even if the application has provided a custom allocator.

`cork_current_allocator` is not libcork specific.  It's job is to allow you to call `cork_new` and friends without having to explicitly pass an allocator instance around.  `cork_new` and friends will allocate (or deallocate) using whichever allocator `cork_current_allocator` resolves to.  In libcork (and as a default for other libraries), it's defined to `cork_allocator` — i.e. `cork_new` in libcork's source files should use libcork's allocator.  If I were to add `clog_allocator` in clogger, then I'd define `cork_current_allocator` to resolve to `clog_allocator` (only in clogger's source files), and then all of clogger's `cork_new` calls would use `clog_allocator`.