rtlib: Fix ThreadDetach race condition/dangling pointer

Previously, a FBTHREAD context was used by threadcreate() to hold the
information about the user's threadproc and about the created thread.
This FBTHREAD context was passed to the rtlib's internal threadproc so it
could call the user's threadproc, and also returned from threadcreate(),
so threadwait() could wait on it and then free it.

With threaddetach() however, it became possible that the FBTHREAD was freed
in threaddetach() before the rtlib's internal threadproc had a chance to
read it (race condition & dangling pointer).

Thus, this patch splits things up: The information about the created thread
and the information about the user's threadproc is stored into 2 separate
contexts, one of which is threadwait's/threaddetach's responsibility to
free, and the other is our internal threadproc's responsibility to free.

Note: This doesn't change FBTHREAD's sizeof(), because even though it could
now be simplified, it's probably better to do in a separate commit in case
it must be reverted.
rtlib: Add a ThreadDetach() for the XBox port too
rtlib: Fix XBox's threadcreate()

I'm not sure but I think the user data pointer should be passed as-is to
the PsCreateSystemThreadEx() function (like with the thread creation
functions of other platforms), as opposed to passing its address.

Either way it looks like this was never tested since the code in the
threadproc() has been commented out ever since it was added in 64dbdfb1.
rtlib: Remove now unused members from the internal FBTHREAD structure

See also 28dca8a79e39954ed21af16c4e9d158457fa75db.
rtlib: Fix XBox threadcreate() to actually return the thread handle
rtlib: Add further commentary to FBTHREAD
rtlib: Make seemingly unused FBTHREAD.opaque field DOS-only

It was added in 16295b4a for DOS apparently, but since FB doesn't even
support threading in its DOS port and the DOS FBTHREAD isn't even used
anywhere in the current rtlib code, I don't think it's needed anymore.

At least this removes the field from the Linux/Win32 versions, which I'm
pretty sure didn't use it and aren't ever going to need it either.