Calculate intersection based on where element would appear rather than where element currently is

[yang]

First, thanks for this wonderful library @morellodev!

Would you consider changing the intersection calculations to use where the element would appear as the subject of the IntersectionObserver, rather than using the element that is being transformed? The former is static and stable, whereas the latter is a moving target and can cause an infinite feedback cycle.

I believe this is the root cause behind a number of other issues on GitHub, including a few that I had spent time digging into (as glitchy behavior), including:

• Setting Fade direction to up starts it from the bottom, so you have to scroll much further down to start trigger. Also reported here: Issue Items do not appear at the right moment when scrolling down. #62
• Setting both fraction and direction when the element starts off clipped (either by an overflow:hidden parent or an artboard iframe) will cause it to never reveal itself or start glitching! Also reported here: Buggy fraction prop #68 and Direction = "top" purple squares glitch when partially in viewport #10