Thread spawn is needlessly unergonomic

[chrysn]

Major downsides are:

• The 'static version takes a &'static mut impl Fn() -- which is hard to create (static_cell), when what one'd really want is passing an impl Fn() because that allows just putting a closure there.
• PRIORITY_MAIN and flags (THREAD_CREATE_STACKTEST) need casting and access to riot_sys

A builder pattern could probably replace the single spawn function.

[chrysn]

It won't be completely trivial to get rid of the need to make R a &mut, as we can only pass in a pointer to the thread callback. We could do some pointer arithmetic, squish the moved R into the stack and let RIOT work with the remainder of the stack (RIOT will do its own alignment shenanigans in there anyway) … not pretty though. Also because the thread can never really free/use that space. It'd be neat if we could pass it into the nascent function the same way a call-by-value would go in, but that'd be architecture specific.

[chrysn]

If we already touch spawn, we could just already make it so that it zombifies the thread at the end, and sets a result value (possibly inside that space that was set aside for the arguments inside an enum StartAguments(R), Result(R2). Could even have a Paniced() variant if we like. Control of that memory is with the threads module, so any spurious zombification would be detectable by the start arguments still being in there. (No point in moving them out -- we've used their size already, let's call them as &mut if we can do that with a FnOnce).

Some const optimization, and it'll be almost the same produced code if all involved is () or pointer sized.

[chrysn]

This is related to https://github.com/RIOT-OS/rust-riot-wrappers/issues/40 and possibly best fixed in one go.

[chrysn]

Also, https://github.com/RIOT-OS/rust-riot-wrappers/issues/24 could be done in the same go as well.