single-thread feature for removing ELF TLS dependency

[EkardNT]

Adds a new feature single-thread which when activated removes the #[thread_local] dependency. The catch is that the user must guarantee that futures will never be polled from more than one thread.

I intend to use this support to allow me to run futures on a STM32F103 board which only has a single core, so the only-one-thread limitation is not a problem. In general I expect this feature to only be used to target similar embedded systems.

[roblabla]

Looking good!

Just a couple things:

1. I'd like the name of the feature to be named "unsafe-single-thread". This is because using that feature in a multi-threaded environment will lead to memory unsafety, and I want to make sure the user is aware of that and properly reads the documentation.

2. There's an important catch when it comes to embedded usage: Interrupts counts as a separate thread as well! So "running your code on a microcontroller that has only a single processor is an
   easy way of guaranteeing that the single-thread contract is upheld." is wrong, and I think should be specifically called out that interrupts are considered their own thread and shouldn't be using await.

[EkardNT]

I added a warning about not polling futures from an interrupt routine. However, are interrupts actually a problem so long as they occur on the same core? I get that the TLS_CX variable wouldn't be automatically restored by the CPU itself when the interrupt returns, but the SetOnDrop logic seems like it would have the same effect.

Example timeline:

1. Program polls a future, installs value A in TLS_CX.
2. Interrupt occurs.
3. Interrupt code polls a future, installs value B in TLS_CX. A is recorded in the SetOnDrop.
4. Interrupt poll completes, value A is restored in TLS_CX.
5. Interrupt completes.
6. Program continues with polling future. It still sees the expected value A in TLS_CX.

Even interrupts within interrupts or chained interrupts would succeed due to to the SetOnDrop logic, right?