Refactoring: Remove state management API

[bryphe]

Revery included a very simple Redux-inspired state-management solution. However, there's no reason to force users into a certain state-management paradigm (we should let the user bring their own state management solution.

For Onivim 2, I'm experimenting with isolinear, which is an Elm-inspired approach that also handles effects.

[msvbg]

This commit breaks my code (per git bisect). The window is completely black until I move the window, at which point rendering resumes.

[bryphe]

Ah, sorry about that @msvbg !

I suspect it is due to the removal of the needsRender tracking variable - it's set to true for the first render, so it guarantees there will always be an initial render. I tested against this change against the example app and Onivim 2, but I suspect it worked in the former due to an animation (marking the window as dirty) and in the latter due to the separate state management we do that would trigger a render. I was able to reproduce with the example by changing the default example to a non-animatable one and removing the Window.setPos call (any change in position / size will mark the window as dirty).

We can add the flag back to ensure there is a first render. I'll put up a shortly. Thanks for reporting!

[bryphe]

This would be a perfect case to have a tool like #156 to avoid regressions like this.

[msvbg]

Indeed, considering how visual Revery is it would make a lot of sense to have that.