A simpler interface for pipelined peers that don't have interesting `Receiver` results

**Is your feature request related to a problem? Please describe.**

It occurred to me that the pipelined mini protocols I'm working on don't have an interesting `c` type. IE the `Receiver`s do have useful side-effects but do not have any result value that would be interesting for the mini protocol `Peer` to react to.

In fact, this seems plausibly to be the common case. The only reason I have so far imagined the `Receiver` result being interesting is if the `Peer` wanted to control the scheduling of any expensive computations instead of promptly doing them whenever the message arrives.

**Describe the solution you'd like**

Disclaimer: I haven't thought this through; I'm merely spelling out my intuition.

I propose:

- Add a `Pipelined_` constructor to `IsPipelined`.
- Add a `YieldPipelined_ :: ... -> Receiver ps pr st' st'' m () -> Peer ps pr Pipelined_ st'' m a -> Peer ps pr Pipelined_ st m a` constructor to `Peer`.
- Provide a driver that doesn't retain the result of each `Receiver`.

**Describe alternatives you've considered**

My "workaround" is to use today's `Pipelined` and settle for calling `collect` whenever possible merely to discard the `()`s that the driver is uselessly retaining each time my `Receiver` runs.

**Are you willing to implement it?**
* [x] Are you? :smiley:

Maybe we could pair program it during a weekly meeting we're in together!