Chain experiments

[FelixPetriconi]

This is my current state of experiments:

• Taking over the cleanup changes from branch sean-parent/forth-chains
• Handling of arguments in segments in RPN manner, popping as many arguments from the stack as possible for the next callable and push the result back onto the stack for the next in the tuple. I was inspired by the Segment in the Rust implementation. Working with callable in the segment that
  • return void
  • take zero arguments
  • have multiple call operators. It that used that can consume the max number of arguments.
• Add example of injecting a cancellation_token
• Add prototype implementation of split. Hereby I added two approaches:
  • The first start() of the fanned out chains triggers the upstream chain and every further argument to an other start() will be ignored.
  • A way to bind the upstream argument to the split and that the first start() of the fanned out chain picks up that value while preserving the type information that is normally passed into with start(). I could think of an alternative or additional approach of passing in a function that returns that value on calling the first time start().
• Add example of move-only types
• Add sync and async example of concatenated chains
• Moving pre_exit() into an extra main.cpp to prevent runtime problems of calling it multiple times which happens in the current setup of the catch2 tests.
• All examples work with VS2022 and Apple Clang 16.0

The biggest change of the existing code is that I changed the passed in receiver into a shared_ptr object to circumvent the problem of the move-only package_task.

Adenum: I tried to make the receiver in start() a value - remove the shared_ptr - keep in the captured lambda and pass from then only a reference, aka receiver_ref<> around. But this does not work, because the lambda inside the tuple will be copied into the invoke. This is not possible because of the removed copy-ctor of package_task.
I don't like the heap allocation, but I don't see at the moment a way around it.

[dabrahams]

If the intention is that this PR be reviewed, it should be broken up into separate PRs each with its own concern.

[FelixPetriconi]

Not really. This PR is more about exchanging ideas in the context of chains.
I started a discussion with Sean about his talk on this subject.

When it comes to the point that something should actually be merged into main then of course everything needs to be split up into smaller portions and targeting the correct files.