Add a sender adaptor for setting the current allocator associated with the receiver

[anthonywilliams]

As described in issue #313 some algorithms may require memory allocation, however there is no mechanism in P2300R3 for specifying which allocator to use for this memory allocation.

In many scenarios it is essential to be able to control memory allocations. I therefore propose adding allocator support to let_value as follows:

• if let_value is invoked as let_value(s,f,alloc) where s is a sender, f is an invocable and alloc is an allocator, then it is equivalent to:
  1. tag_invoke(execution::let_value, get_completion_scheduler<set_value_t>(s), s, f, alloc), if that expression is valid and its type satisfies execution::sender, otherwise
  2. tag_invoke(execution::let_value,s,f,alloc) if that expression is valid and its type satisfies execution::sender, otherwise
  3. tag_invoke(execution::let_value, get_completion_scheduler<set_value_t>(s), s, f), if that expression is valid and its type satisfies execution::sender, otherwise
  4. tag_invoke(execution::let_value,s,f) if that expression is valid and its type satisfies execution::sender, otherwise
  5. let_value(s,f), except that a copy of alloc is used for all dynamic allocations performed in order to meet the required behaviour of let_value.

let_error and any other algorithms that can allocate should be adjusted in a similar fashion.

[ericniebler]

In sender/receiver, state like allocators isn't passed into the algorithm; it is associated with the receiver with queries like get_allocator(Receiver). If you know the allocator when you are calling the algorithm and want it to be used, you would write a sender adaptor with_allocator(Sender, Allocator) that, when connect-ed, would wrap the incoming receiver with one that implemented the get_allocator query and returned the allocator.

EDIT: Rather than forcing the world to write with_allocator, P2300 would do well to ship with sender adaptors that correspond to the existing receiver queries. My $0.02.

[anthonywilliams]

OK: if get_allocator is the way to go, then we need with_allocator in the paper.

[ericniebler]

We'll probably want several of these sender adaptors; e.g., for setting the current scheduler, or the current stop token. In libunifex, we have just one sender adaptor that can be parameterized on a receiver query CPO, which might be the right way to go here.

[ericniebler]

moved to cplusplus/sender-receiver#56