Introduce get_return_object_on_allocation_failure to Lazy

[ChuanqiXu9]

This patch tries to introduce get_return_object_on_allocation_failure() to the promise_type of Lazy.

Why do we want to introduce get_return_object_on_allocation_failure()? Since
a coroutine will be roughly converted to:

void *frame_addr = ::operator new(required size);
__promise_ = new (frame_addr) __promise_type(...);
__return_object_ = __promise_.get_return_object();
co_await __promise_.initial_suspend();
try {
    function-body
} catch (...) {
    __promise_.unhandled_exception();
}
co_await __promise_.final_suspend();

Then we can find that the coroutine should be nounwind (noexcept) naturally if
the constructor of the promise_type, the get_return_object() function, the
initial_suspend, the unhandled_exception(), the final_suspend and the allocation
function is noexcept.

For the specific coroutine type, Lazy, all the above except the allocation function
is noexcept. So that we can make every Lazy function noexcept naturally if we make
the allocation function nothrow. This is the reason why we want to introduce
get_return_object_on_allocation_failure() to Lazy.

Note that the optimization may not work in some platforms due the ABI limitations.
Since they need to consider the case that the destructor of an exception can throw
exceptions.

[RainMark]

这里的exception什么时候被用户touch到

[ChuanqiXu9]

当该协程被 resume 时，在 await_resume 中会抛出异常

[RainMark]

多个线程同时出现了bad alloc，是否会有race

[ChuanqiXu9]

hmmm 好像是不太对，这种情况因为平时不会耗尽内存所以没遇到，我先 revert 吧

[RainMark]

其实这里有点尴尬，bad alloc时一般都是内存比较紧张了。只好提前分配比较合理，thread local是不是可以解，没特别想清楚