Generalized lifting/unlifting effect

[robrix]

This PR explores using the facilities introduced in #296 to unlift monads. (Edit: The dependency on #296’s features is no longer present.)

• Depends on 🔥 Pure & PureC #307.
• Defines an Unlift effect and carrier. Improves the definition of Lift to support unlifting.
• 🔥s the MonadUnliftIO instances & dependency on unliftio-core.
• Control.Effect.Exception should probably live in fused-effects-exceptions instead.
• Tests for Lift/LiftC.

[KingoftheHomeless]

This is the corresponding effect to polysemy's Final effect. You may like to look into the Strategic environment which we provide for making it easier to use the effect. (Currently in the process of being reworked over at polysemy: polysemy-research/polysemy#239)

[patrickt]

This is really, really mindblowing. I love this, and I think it's a real leap forward for the expressivity of our library. (Consider how nice this would be atop STM.)

I have thoughts (below), but I'm 100% in favor of this. Great stuff.

[KingoftheHomeless]

In polysemy we chose to separate Final (this new Lift) from Embed (your old Lift) because Final is invariant in the parametrized monad, while Embed is covariant in the parametrized monad.
Embed is thus more flexible to interpret, which can seen in the differences between runEmbedded and finalToFinal.

[robrix]

@KingoftheHomeless thanks for the comparison!

[ilyakooo0]

Could you give an example of how to implement MonadUnliftIO for a custom carrier with liftWith?

Or just provide an example of the general use case for how the new Lift replaces the need for MonadUnliftIO instances.