Break up tight coupling between worker and rendering logic and state

[mourner]

Historically, most internal GL JS classes had mixed responsibilities, doing both worker and main thread work and sharing tons of state in between. #5143 removed a lot of serialization boilerplate to make it easier to transfer class instances, but also made the situation harder to control — internal state is now shared between threads implicitly and we haven't really paid close attention to how much of it is necessary to share. There were targeted fixes for the worst bottlenecks (see PRs linked in #7011), but the general problem remains — deserialization on the main thread still takes noticeable CPU time (some of it not shown in profiles because JSON structured cloning with postMessage isn't attributed explicitly).

Additionally, the logic is so tangled now that makes it very hard to understand which of it happens on the main thread, which is on the worker side, and which should be shared intentionally. This contributes to the worker bundle being almost as big as the main thread one, increasing time-to-first-render.

So let's discuss what we could do to address this. I think that since our goal is to eventually minimize logic and state sharing and tight coupling between threads, we should:

• Revert back to explicit serialization.
• Switch to raw buffer transfer instead of class instances where possible.
• Start breaking up various classes like layer buckets into separate ones (render-side and worker-side).

The clearer and more explicit the separation between render-side and worker-side logic, and between shared, temporary and persistent state, the better.

I'm not sure how this correlates with GL Native codebase (especially given that there are considerable architectural differences) (cc @kkaefer), but we've accumulated a lot of technical debt on this front in GL JS and I'd love to see if we could address it this year.

cc @mapbox/gl-js