Fix bugs in as_awaitable, let_error and sync_wait

[Cra3z]

execution/include/beman/execution/detail/let.hpp

Lines 273 to 278 in 8c46474

	template <typename Receiver, typename... Args>
	static auto
	let_bind(auto& state, Receiver& receiver, Args&&... args) noexcept(noexcept(::beman::execution::connect(
	::std::apply(::std::move(state.fun),
	::std::move(state.args.template emplace<::beman::execution::detail::decayed_tuple<Args...>>(
	::std::forward<Args>(args)...))),

The following code fails to compile due to an issue in the current let algorithm implementation. Since std::variant::emplace is never noexcept, noexcept(let_bind(...)) always resolves to false. This imposes a requirement that the let sender's receiver must support an error channel (set_error), causing the compilation failure for the code below.

ex::simple_counting_scope scope;
ex::spawn(
    ex::just_error(0) | ex::let_error([](int) noexcept { return ex::just(); }),
    scope.get_token()
);

[coveralls]

coverage: 95.084% (-0.004%) from 95.088% — Cra3z:main into bemanproject:main

[Cra3z]

I've noticed a data-race in run_loop/sync_wait and fixed it in 79368fe, here is the minimal repro:

ex::run_loop loop;
std::jthread worker{[&loop] {
    loop.run();
}};
auto _ = ex::sync_wait(ex::just() | ex::continues_on(loop.get_scheduler())).value();
loop.finish();

execution/include/beman/execution/detail/run_loop.hpp

Lines 177 to 183 in 8c46474

	auto finish() -> void {
	{
	::std::lock_guard guard(this->mutex);
	this->current_state = state::finishing;
	}
	this->condition.notify_one();
	}

Can't unlock before notify_one, otherwise it will trigger the similar scenario as demonstrated in https://gcc.godbolt.org/z/zanf1avxa