We lookup freed extents for testing in post_reset.  Take background_thread lock
so that the extents are not modified at the same time.

Avoid calling pthread_create in postfork handlers.

To avoid complications, avoid invoking pthread_create "internally", instead rely
on thread0 to launch new threads, and also terminating threads when asked.

Also fix a compilation error #ifndef JEMALLOC_PTHREAD_CREATE_WRAPPER.

Pre-C11 compilers do not support typedef redefinition.

Avoid holding arenas_lock and background_thread_lock when creating background
threads, because pthread_create may take internal locks, and potentially cause
deadlock with jemalloc internal locks.

Since tsd cleanup isn't guaranteed when reincarnated, we set up tsd in a way
that needs no cleanup, by making it going through slow path instead.

It's possible to customize the extent_hooks while still using part of the
default implementation.

This makes sure we go down slow path w/ a0 in init.

The state initialization should be done before pthread_create.

Add testing for background_thread:true, and condition a xallocx() -->
rallocx() escalation assertion to allow for spurious in-place rallocx()
following xallocx() failure.

Refactor bootstrapping such that dlsym() is called during the
bootstrapping phase that can tolerate reentrant allocation.

Previously we could still hit these assertions down error paths or in the
extended API.

This resolves #528.

Use a separate boolean to track the enabled status, instead of leaving the
global background thread status inconsistent.

This resolves #507.

This resolves #412.

This resolves #669.

We do not lock extents while advancing epoch.  This change makes sure that we
only read npages from extents once in order to avoid any inconsistency.

Fix management of extent_grow_next to serialize operations that may grow
retained memory.  This assures that the sizes of the newly allocated
extents correspond to the size classes in the intended growth sequence.

Fix management of extent_grow_next to skip size classes if a request is
too large to be satisfied by the next size in the growth sequence.  This
avoids the potential for an arbitrary number of requests to bypass
triggering extent_grow_next increases.

This resolves #858.