Should the `receiver` concept require that move-construction is nothrow?

[lewissbaker]

The receiver concept as currently defined requires that the type is move_constructible but does not require that the move-constructor is noexcept.

For algorithms like let_value() that chain together multiple senders and need to call connect() after start() as been called, it can be difficult to accurately compute the set of completion-signatures since we cannot know whether or not the connect() method will be noexcept until we have a receiver, and the connect() method will generally need to be conditionally noexcept based on the whether or not the receiver is nothrow move-constructible.

If we require the receiver concept to be nothrow move constructible then we can remove some of the dependence of connect()'s noexceptness on the receiver type.

However, this still leaves open the question of how to query whether connect() on a child sender will be noexcept before we know what receiver we are going to give it and therefore what overload we will call.

One option would be to query noexcept(stdexec::connect(sndr, archetype_receiver_with_env<Env>>{})) and require that the answer be the same for any receiver that has the same Env type.

Another option would be to add another query, similar to get_completion_signatures() on the sender, to ask if it's connect() operation is noexcept or not (assuming it is not dependent on the receiver type and only dependent on the env type).

[lewissbaker]

Marking P0 as this is something we cannot change later.

Related to #247