Abstract coroutine implementation about may

[Xudong-Huang]

thanks @s-panferov. Yes, I also notice those attempts that trying to make coroutine based systems. Actually those libraries such as mioco and coio-rs are started very earlier than I begin to develop May. But I have very little experience in using those libraries.

Coroutines are just user space threads, so the most sensible abstraction over coroutines is supply a thread like API set for it, and user can have the freedom to switch to any kind of implementations. e.g.
std::thread::* vs may::coroutine::* and other libraries could be something like xxx::coroutine::*

not only the thread model should be compatible, but all kinds of blocked version APIs such as IO and Sync Primitives should all be compatible with libstd

Actually go! macro is just a thin wrapper around the unsafe spawn API, which would save users some types. And in coroutine you should never call yield, this is a generator concept. in coroutines, users only have normal system APIs.

Yes, it's possible to have a "front" wrapper library, but it's not an easy thing that all coroutine libraries that support the same compatible APIs.