fix the customization domain of the `on` algorithm

[ericniebler]

as currently specified, for the expression on(sch, sndr), the starting domain is the receiver's domain, and the (set_value) completion domain is sndr's completion domain, given that it starts on sch. those are the two domains that will be used to find customizations of on, neither of which is the domain of sch.

presumably, if a user wants to customize on, they would expect on(sch, sndr) to use the domain of sch to find the customization. so there is a gap between what would be least surprising and what is currently specified.

in [P3927], we added a get_completion_domain<T> query where T could be either a completion tag (set_value_t, et. al) or void (and defaults to void), where get_completion_domain<void> defaults to get_completion_domain<set_value_t>.

get_completion_domain<void>(get_env(sndr), env) is the domain that gets used by transform_sender to find a set_value sender transform. in other words, transform_sender(sndr, env) will, among other things, apply the following transform:

auto sndr2 = get_completion_domain<>(get_env(sndr), env)
                .transform_sender(set_value, forward<Sndr>(sndr), env);

we can use this to query to make transform_sender use the domain of sch to find a customization of on(sch, sndr).

Proposed Resolution

9. Let out_sndr be a subexpression denoting a sender returned from on(sch, sndr) or one equal to such, and let OutSndr be the type decltype((out_sndr)). For a pack of subexpressions env, get_completion_domain<>(get_env(out_sndr), env...) is expression-equivalent to get_completion_domain<set_value_t>(sch, env...). Let out_rcvr be a subexpression denoting a receiver that has an environment of type Env such that sender_in<OutSndr, Env> is true. Let op be an lvalue referring to the operation state that results from connecting out_sndr with out_rcvr. Calling start(op) shall [...]