Change design of Observer to allow pooling listeners

[boatbomber]

Instead of creating a new Observer every time, there should be some form of sharing whenever possible. If two Observers are watching the same state, it should really just be one Observer with two listener callbacks.

[dphfox]

I'm going to hijack this issue with a radical idea; what if we got rid of Observer entirely as a user-facing construct? Nobody actually uses them for anything except immediately piping it into an :onChange() or :onBind() call.

Things have changed a lot since 0.1 when this API surface was first introduced. Now that we have scopes, we've externalised all destruction tracking, so we can append code into the current scope to handle disconnecting the listener. Beyond that, what purpose does Observer as a public-facing construct serve?

So my proposition is this; drop the API entirely, and replace Observer with a function, observe() or onChange() or something like that. As far as the user cares, those functions connect the callback to be run in a new coroutine at some point soon after an update occurs. Maybe it also provides some nice options to track multiple state objects or run the callback immediately to match onBind - I don't know, but all that matters is there's no object involved.

Under the hood, Fusion can now internally manage whatever reactive graph mechanisms it needs in order to dispatch those listeners. Fusion can count the number of listeners so that it destroys whatever internal objects its using once all listeners are disconnected.

From there, observe() becomes the foundation atop which we can build other APIs, like perhaps a general connector for binding instances to properties, which can then be used in applyInstanceProps (#304)