Increase purity by introducing F[_] to Sink, Source and Cancelable

[busti]

This pull request aims to add polymorphic F[_] effect types to the onNext, onError and subscribe functions found in Sink and Souce. This is to make integrating libraries like zio_stream or fs2 easier and most importantly safer / purer.

The pull request is based on #122 since it makes it a lot easier to implement F[_] in many places.

This is still a work in progress, at the moment this PR mostly serves to keep people informed about the progress on this and to encourage discussion.

---

This change was previously being tracked in #123 but unfortunately the branch got deleted, which resulted in closing the PR.
I wanted to rename the branch while the PR was open, which github should support when done from inside github, but that seems to have failed.

[cornerman]

I really like what you have done in this PR, but, I think, we both had to realize that this adds a lot of complexity (and might as well affect performance/allocations). But i am also not sure about it really.
Facing the update to cats-effect 3, I have now tried to do this in a more pragmatic approach. That is: all side-effecting functions like subscribe, onNext, onError, cancel are now called unsafe* to clearly signal the impure nature of these methods to the user.
There are now referential transparent methods like subscribeF, onNextF, onErrorF, cancelF that just call the unsafe* methods inside of a effect. They are meant to be used by the users of this library.

See #167

[cornerman]

But actually i would like to try to move this on top of cats effect 3. I wonder whether we could properly integrate with effect types apart from IO.

[busti]

I think, we both had to realize that this adds a lot of complexity

Realizing that kinda made me give up and move over to trying to find other ways to abstract the problem away elsewhere, which is why I haven't made any further commits here.
While I do believe continuing this effort is possible, I think the complexity it adds is not worth the effort, not to mention the cognitive load when trying to think about execution order with the excessive usage of cats.syntax algebra.

I tried another kind of abstraction in my project https://github.com/busti/hummingbird (pun intended), but it's just as complicated in different ways and a bit dirty since the core abstraction relies on emitting one artifact per supported streaming lib by dynamically switching out those libraries in the build file.