Change member-functions over to use tag_invoke

[lewissbaker]

The paper P2300R0 proposes having all CPOs used for senders be purely tag_invoke based and not dispatch to member functions.

To be consistent with this, we should do a pass to change over .connect(), .start(), .set_value/error/done() and .schedule() methods to be tag_invoke-based customisations and to change the CPOs to only dispatch through to tag_invoke customisations.

[ericniebler]

With specific regards to .set_value/error/done(), I'm not a huge fan of dropping support for customization-via-member-function. I like the ability to implement algorithms with custom receivers by defining receiver member functions. The other CPOs I care less about.

[lewissbaker]

My main concern is that what is currently proposed in P2300R0 does not allow customisation by defining member functions and yet we are doing that in libunifex which makes it harder to argue that libunifex is a kind of reference implementation for the sender/receiver proposal.

If we strongly feel that we should make an exception for the receiver type (and I'm not yet convinced we should) then we should consider also extending this exception to the proposed paper. If we do this, I think we should try to analyse what is different about receivers compared to, say, other kinds of types that want to use tag_invoke-based CPOs to see if we can come up with a recommendation for when to use tag_invoke-only and when to allow dispatch to member functions.