Data races in freeGroup

The block allocator's freeGroup function commits a rather serious concurrency sin in its block coalescence logic: When freeing a block it looks at bd->free of the previous/next block to see whether it is allocated. However, the free'ing thread likely does not own the previous/next block, nor do we make any attempt to synchronize with the thread that does own it; this makes this access a data race.

The original design argued that this was correct because bd->free will only take a value of -1 when the block is free and thereby owned by the storage manager. However, this is nevertheless unsafe under the C11 data model, which guarantees no particular semantics for data races.

We currently assume (and hope) we won't see torn values and consequently we will never see bd->free == -1 for an allocated block which we do not own. However, this is all extremely dodgy and really ought to be revisited.