Complete thread-safety

[nelsonxb]

While multiple threads can have their own coroutines, this is not documented, and an individual coroutine is not safe for thread migration.

• Make thread activation/deactivation atomic;
• Document this behaviour;
• Find some way to deal with thread-locals.

[nelsonxb]

Thread-locals will probably be dealt with by documenting their caveats (and discouraging their use).

[nelsonxb]

This has been implemented early for x86_64, however there are not yet tests guaranteeing this. As such, new platforms may be considered acceptable without mimicking this behaviour.

To clarify, the general strategy here is to guarantee that a coroutine can't be resumed twice. The only thing that is changing here is guaranteeing that this cannot happen in a multi-threading context. The only thing that's really needed to assert this, is to make the process of activating a coroutine atomic. Since (due to the atomic activation) it is guaranteed that an await will only ever occur on a single thread at a time for a given coroutine, all that green_await() needs to do is make sure it's finished operating within the coroutine before it gets marked as deactivated.

[nelsonxb]

Same thing should be implemented in AArch64, too. Again, hard to test this.