A pthread created with the attribute
	pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
Does not need to be pthread_join()ed - and its resources, most importantly
its stack, should be deleted as soon as it is done.

Previously, we ignored this mode, causing its users (Java uses it for all
its threads!) which do not ever pthread_join() on these threads, to leak
the threads' stacks.

This patch adds support for this mode, and adds a test to tst_leak.cc
which verifies that before the patch, we had a leak, and now we don't.

Unfortunately, this patch is a bit ugly, and I was surprised how much time
it took me to actually get it to work :( Because of the convoluted
relationships between pthread_*, pthread_private::pthread, sched::thread
and sched::detached_thread, I ended up, after many rewrites (!) duplicating
the "reaper" code from sched::detached_thread to do something very similar
for detached pthreads. I.e., when a detached pthread finishes, it can't
pthread_join() itself (which would cause a mess as it destroys its own
stack) so instead it tells a different thread, the "reaper" thread, to
run this pthread_join().

In the future it would be nice to create one generic "reaper" which
is used by both detached sched::threads and pthreads, or even find
a way to allow a thread to pthread_join itself as its last action.