Tee implementation without Clone requirement

[frankmcsherry]

This is a bit of a proof of concept, stealing a bit from @antiguru's PR.

The goal is to support a Tee that does not have an inherent Clone requirement. Currently, the requirement exists because Tee itself is responsible for cloning containers when there are multiple consumers, and we need to have Tee to support any number of consumers.

The change here is to use a Box<dyn Push<T>> for the Tee, whose implementor either is or is not able to clone pushed containers, and handles that call without constraining Tee. The two implementors, PushOne and PushMany, respectively do not and do require Clone. The logic is set up so that the TeeHelper installs a PushMany only as the second pushee, and doing so could in principle live behind a method that has the C: Clone constraint.

It's not certain how to proceed, other than stealing further from @antiguru. Any concrete TeeHelper or StreamCore would need to either require Clone or not, and the ability to use it would depend on how we set that up. It seems "easy" to have two distinct types, but @antiguru reports that perhaps this is not necessary (the Streamlike trait not being required). Further investigation / copying is required!

---

Update: this proceeded to borrow more from @antiguru's work, with some ergonomic improvements (using Clone rather than tee and owned, which I give even odds we will end up regretting due to "too-clever-ness" footguns. We'll see).

[antiguru]

Looks good! Note to our future selves: we could likely change the input infrastructure to use the same pattern instead of requiring the data to be clone.

[frankmcsherry]

Thanks very much for the help, and the inspiration!