Appworker based Delta Updates

While this happens very rarely, I am going to hold off on this one. @rwaters

I missed the point, that in case we are running vdom OPs inside the app & vdom worker, vnode ids will no longer be unique (due to 2 separate id generators).

My first thought that this could be easily resolved with using a SAB: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

=> Storing the dynamic vnode id counter inside of it so that both workers have direct access to the shared counter for creating ids.

However, SABs are now strictly limited to cross origin isolation: https://web.dev/articles/cross-origin-isolation-guide

In case it is not enabled (e.g. inside the webpack dev server or the Webstorm dev server), the SAB ctor is simply undefined.

I do get the point, that worker files (scripts) need to share the same origin, but enforcing entire apps to do it goes too far.

While it often is a good thing to go for COI, enforcing it for all future neo apps goes is not reasonable.

With the v8 release, we will get scoped vdom updates which can drastically reduce the footprints of search trees and worker messages. While we could move the entire vdom engine into the app worker, having the buffering to get less tree parsing is also something we do not want to lose.