as-receiver::set_error() should accept any error type, not just std::exception_ptr

[lewissbaker]

From https://github.com/executors/executors/pull/458/files/a29443f3071e13863bcc3c34930b1c0030f96d3c#r384097410

The as-receiver type in the wording for execution::execute() is currently defined as:

template<class F, class>
struct as-receiver {
  F f_;
  void set_value() noexcept(is_nothrow_invocable_v<F&>) {
    invoke(f_);
  }
  [[noreturn]] void set_error(std::exception_ptr) noexcept {
    terminate();
  }
  void set_done() noexcept {}
};

The purpose of this class is to adapt an invocable object as a receiver so that it can be passed into the submit() function of a sender in the case that a sender is passed instead of an executor that natively implements the execute() function.

However, the set_error() method is currently limited to only accepting a std::exception_ptr whereas it's possible that the sender might call different overloads of set_error() with other error types. e.g. std::error_code or some other application-specific error type.

The overload of set_error() should be able to accept any error type send by the sender, not just std::exception_ptr. It should be changed to be a template-function with a deduced parameter.

e.g.

-[[noreturn]] void set_error(std::exception_ptr) noexcept {
+template<class E>
+[[noreturn]] void set_error(E&&) noexcept {
   terminate();
  }

However, this also raises a larger question about whether or not the set_error() customisation-point itself should be handling the type-erasure of other error types into the std::exception_ptr type so that receiver implementations can just implement set_error(std::exception_ptr) and know that whatever error type is sent by a sender will be converted to a std::exception_ptr.
This might in turn require another customisation-point for customising the conversion. eg. so that std::error_code is converted to a std::exception_ptr that holds a std::system_error containing the std::error_code. Other application-defined error types might want to customise their conversion to std::exception_ptr.

[jaredhoberock]

However, this also raises a larger question about whether or not the set_error() customisation-point itself should be handling the type-erasure of other error types into the std::exception_ptr type so that receiver implementations can just implement set_error(std::exception_ptr) and know that whatever error type is sent by a sender will be converted to a std::exception_ptr.
This might in turn require another customisation-point for customising the conversion. eg. so that std::error_code is converted to a std::exception_ptr that holds a std::system_error containing the std::error_code. Other application-defined error types might want to customise their conversion to std::exception_ptr.

@lewissbaker - I'm resolving the initial editorial concern raised by this issue, so please raise these additional concerns in a separate issue if you feel that they require further review.