Adds the ability to attach ad-hoc processors to optimize

[mikesol]

This PR is the start of an exploration into the idea of fusing together deku nodes during a processing step.

To do this, I've reorganized the repo using the new spago, which lends itself well to a setup where there's both a lib and an executable.

The idea is that everything in lib would be published to the registry as a library. Then, everything in postinstall would run as the npm postinstall step in order to build the optimizer with any processors that are present.

It's a bit of a chicken-egg, because the package needs to exist as a lib before external processors can depend on it. But once that's overcome, people can build their processors against the lib and then backend-es can be built against those custom processors.

Unfortunately the PR looks much bigger than it is because so much stuff is moved around. All it's really doing is swapping in the new spago, adding a step to use the processors, and adding a stub for the postinstall. Once the lib is published, the postinstall stub can be unstubbed.

This PR is just to get the conversation going - while it works, I'm not particularly attached to the approach. So we can either validate the approach, suggest alternative ones, or rule out processors altogether if they seem too onerous. I borrowed the design from Unreal, which makes the engine open source so that folks can pull in libs that mod it.

[mikesol]

Hm... it looks like bundling on windows isn't working but otherwise the PR/approach is ready for discussion.

[mikesol]

@natefaubion I revamped the PR to use the current spago.

[mikesol]

I also got rid of Cofree and have a two processing passes at the head & the tail of the optimization process.

[mikesol]

I just hit a situation in my work on WebGPU where I needed to trigger a rewrite from a processor. I tweaked the processors to be Cofree again but took away the intermediary steps. Now they only fire at the beginning and end of optimize chains.