Resolves #8471

Changes

tl;dr is that having all drawing go to a main framebuffer and then having that get drawn to the main canvas at the end of a frame introduced some sometimes-unnecessary bottlenecks that prevent WebGPU from pipelining multiple frames. So now:

• We avoid drawing to a main framebuffer unless it's actually required
• Any time you use a filter or read pixels, we copy the canvas's state to the main framebuffer and continue on the framebuffer until the end of the frame
• At the end of a frame, if we've been promoted to using a framebuffer, we draw it to the main canvas, but using special shader that removes all unnecessary bits for the sake of speed
• At the start of the next frame, we start in a pending state. If you call background() or clear(), we can continue on the main canvas. If you do anything else, visuals can accumulate, so we continue on the main framebuffer, which doesn't get reset.

Additionally, I made some changes to not antialias the main canvas, but to antialias the main framebuffer so that draws from the main framebuffer to the main canvas can be as fast as possible. But also this means that if we draw right to the main canvas now, it's not antialiased, so some future TODOs include:

• Make sure the main canvas is antialiased if we're drawing right to it and antialiasing is enabled
• Also, let the user control antialiasing -- pretty sure this is not implemented yet

Live thing to play around with: https://editor.p5js.org/davepagurek/sketches/X9gvQfYSN

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated