[execution.senders.adaptors.bulk] Should clarify that bulk customisations are allowed to decay-copy 'args' if required

[lewissbaker]

The current wording indicates that when the input sender sends args that customisations of bulk must invoke f(i, args...) for each i in 0..shape.

However, if the customisation of bulk wants to execute f on some other context it will need to be done asynchronously and thus the implementation will need to decay-copy args to some temporary storage in the operation-state so that they are still available when f is to be invoked.

Should the wording be made explicit here that f is allowed to be invoked with a decay-copied version of args... instead of the same args... that were passed to set_value()?
If so, should the bulk operation be required to complete with a pack of values with the same value category as the predecessor completed with, or is completing with xvalues referencing the decay-copied versions an acceptable transformation of the value-channel for bulk implementations that need to decay-copy the args?

Also, should we be explicit that f is invoked with lvalue references to args... or the decay-copied args...?
If so, are customisations required to pass the same lvalues to each invocation of f?`
If so can we clarify that in the wording too?

[lewissbaker]

Also, we need to add a requirement that customisations must complete with set_value(out_r, args...).
And also that if s completes with set_error or set_done that this result is forwarded through as the result of the bulk operation and that f is not invoked.