Lazy evaluation / hybrid push-pull execution model

[dphfox]

Closes #144. Implements Reactively's hybrid push-pull algorithm for Fusion's graph objects, as described on Technical Fluff and as described by Reactively's author.

[dphfox]

Closes #303.

[dphfox]

Diverged a bit from the algorithm as written. Now, it only paints validity/invalidity, as well as storing a change time for avoiding computations for non-meaningful changes.

[dphfox]

New algorithm documented on Technical Fluff: https://fluff.blog/2024/04/16/monotonic-painting.html

[dphfox]

So I've been playing around with the bugs in this branch for a short while this evening. As best as I can tell, this branch messes up the lifetimes of something somehow - I suspect something that promises to create a new inner scope for a callback is instead returning an outer scope somewhere. Just a hunch.

[dphfox]

Fixed some of the major lifetime issues - after a lot of diagnosis, it turns out the issue was that New calls were being cached, which is incorrect because scope upvalues were being used in the cached functions.

[dphfox]

Ported the Word Game example just fine... so looks like I'll need a more complex example to figure out what's going wrong.

[dphfox]

if you create a tween with a repeat count of -1 then the first time its evaluated self._activeFrom is nil so it sets self._activeElapsed to self._activeDuration (which is infinity) which then causes getTweenRatio to return nan so it gives a warning

Will need to fix this

[dphfox]

Will also need to fix the infinite loop check in change to allow for cyclic changes if they happen through a dependency that doesn't meaningfully change (likely, this just means allowing cycles in change).

[dphfox]

Something I realise now about the way that execution should work; the oldest graph objects should be evaluated first.

Here's why; suppose that there's an Observer A which creates or destroys another Observer B watching the same state. This is a simple dynamic graph.

First observation: every time an evaluate runs, we no longer know what the graph is going to look like. The current code does not account for this, so scope == nil checks should be added.

Second observation: intuitively, if Observer A decides to destroy B, then B should not be given the chance to evaluate. This isn't guaranteed either because eager evaluation order is not specified by change. So Fusion should track creation time and sort by it before executing eager objects.

https://fluff.blog/2024/07/14/glitches-in-dynamic-reactive-graphs.html