Mutexes are now allocation free and thus safe for use within the allocator.

Need to replace with something cleverer later.

Initial memory is physical; the mmu converts it to virtual addresses, and
then it can be added to the memory pool.  Right now there is not much
difference, but the 1:1 mapping is moving soon.

found by the glibc testsuite

When we free the last object in a page, we free the page itself, removing
it from the pool's page list.  However, pages with no free objects are not
present on the free page list, causing corruption.

The only condition this can happen is if there is exactly one object on a
page; so it's simultaneously the last allocated and the last freed object.

An off-by-one meant the the object pool for sizes above half a page was
not initialized.

Currently the free memory pool consists of a statically allocated buffer.
Replace it with a dynamic query of the amount of memory we actually booted with.

(currently limited to 1GB since we haven't mapped anything else yet).

We currently leak a pool page, because we cannot unlink the free objects
belonging to the page from the pool's free list.

Fix by having a per-page free list (containing objects only from that page).
The pages are themselves placed on a doubly linked list.  When we identify
an empty page, we can now easily drop it since the local free list only
point within the page.

We kept pool::_free pointing at a freed object.  Naturally things did not
work well.

Fix by nulling the pointer for now, however this leaks the rest of the free
list.

Must be large enough to hold a free_object.

Pages allocated with alloc_page() have no metadata, so we must format the
header before returing it to the free range tree.

This implementation stores small objects in pools of similar-sized objects,
while large objects are allocated using a first-fit algorithm.  There is also
a specialized interface for allocating aligned pages.