Refactor fill extrusion texture/fbo cache

[mourner]

@lbud @jfirebaugh this is just a quick exploration of how caching textures in style layer objects would look. I would highly benefit from something like this in #5253 because I need to cache two types of textures that differ from the fill extrusion use case — a half-float screen-sized texture downscaled by 4, and a 256x1 RGBA color ramp texture.

Heatmap-specific caching logic in painter.js would look really bad, and while I agree it's awkward to cache render-specific stuff in style layers and look forward to RenderLayer-introducing refactor, for now this seems like a lesser evil than writing lots of layer-specific code in painter.js.

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality (covered by render tests)
• document any changes to public APIs
• post benchmark scores there are no benchmarks with extrusions
• manually test the debug page

[jfirebaugh]

Looks reasonable to me.

BTW, do these GL resources get deleted if the layer or map is removed? (This may have already been an issue with the existing code.)

[mourner]

@jfirebaugh thanks! I think this is an issue with existing code independent of this PR. Not sure how WebGL handles those resources though — does a WebGL texture/framebuffer get destroyed automatically if it's not bound to a context and reached zero references for GC?

[jfirebaugh]

Yeah, the GL resource will be released when the JS object is GC'd, but generally its' a good idea to manually release them when you know they're unused. GC doesn't always happen as quickly as you'd like, or sometimes there can be an outstanding reference to a GL object that's actually no longer needed.

[mourner]

@jfirebaugh I think we can add another noop method to style layers, destroy, that has clean up code in child classes if necessary. We can later move them after the RenderLayer refactor.