This adds a feature to support using parking_lot locks in
`#[global_allocator]` implementations. The main hazard is parking_lot calling
into the global allocator, and then the global allocator calling back into
parking_lot, at a point where parking_lot is not prepared to be re-entered on
the same thread.

There are currently two places where this comes up:

 - When a new thread is created, parking_lot needs to allocate space in its
   hashtable for the new thread. It uses the global allocator to allocate this
   space, and if the global allocator uses parking lot, it doesn't work because
   the hashtable is not ready for the new thread yet.

 - If the new hashtable is allocated while bucket locks are held, and the
   global allocator attempts to acquire a parking lot lock, it deadlocks
   because all the buckets are locked.

This defines a new "global_allocator_compat" feature. When defined:

The hashtable growing code checks whether it's being reentered, and does no
growth in that case.

And, `create_hashtable` will allocate the new `HashTable` before locking all
the bucket locks, to avoid deadlock if allocating the `HashTable` attempts to
take a lock.

And, a new function, `init`, is defined, for allocating the initial
hashtable. This must be done before performing any syncronization.