Thread creation: Don't rely on TCB being inside stack

[chrysn]

riot-rs has its thread_t somewhere else than in the stack.

The conclusion of RIOT-OS/RIOT#17542 is that for creating a thread and getting its thread_t, creating it stopped (no-one goes around unstopping nascent threads unless they're it by what this mechanisms avoids), and looking at its thread_t before it's had an opportunity to stop, then run it.

This doesn't solve the issue on its own (because now that the thread_t may is not owned by us, we can't be sure it's not repurposed), but rather than doing a test for identity we can still check whether the sp is within the stack we allocated, so we can know whether it's still our thread.

Then again, this could become moot with anything that's more along the lines of a thread not being reaped until it's reaped by someone responsible, but right now nothing along these lines is available.

[chrysn]

There's two things wrong with the current TrackedThread:

• It looks at the TCB, which may be outside the stack
• Even if it looked at the stack instead, the stack (or the current TCB pointer) is a lifetimeless pointer, so if the thread's stack gets deallocated and reused, there'd still be confusion about the tracked thread's status. Either the type needs to inherit some of the stack's lifetime (as to be sure that the stack was not reused), or needs to work in a completely different fashion.