pthread_barrier_destroy is unsafe

After hitting the barrier count, each thread does additional bookkeeping before returning from pthread_barrier_wait. If a fast thread then calls pthread_barrier_destroy (and frees the underlying memory), a slow thread can end up with a SEGV. Now, POSIX says

> The results are undefined if pthread_barrier_destroy() is called when any thread is blocked on the barrier

but I think this does not apply here because the threads are no longer *blocked on the barrier* after the condition is reached. Other libc implementations have special code to handle this situation (typically by somehow synchronizing the _destroy call with exiting waiters).

I ran into this in the test for pthread_getattr_np (#221231). What makes this bug particularly annoying, is it means one needs to use *another* synchronization primitive in order to destroy the barrier safely. Normally one could use pthread_join() (that's what the barrier test does, which is why it doesn't catch this), but here I explicitly need to test detached threads.

(@uzairnawaz @brooksmoses @SchrodingerZhu )