WebGL render backend

[Herschel]

This adds a WebGL1 rendering backend for use on web.

• Moved render backends to subcrates in the top-level render directory because backends may share common code and potentially work on multiple platforms
• lyon based tessellation code was moved to render/common_tess and is used by both the desktop and WebGL backends
• This also paves the way for a WebGPU backend which could be used on both desktop and web (Switch to webgpu-rs for rendering backend #14)
• Opinions welcome (is this a good organization for the render backends? Should we do this for all backends? Should we just cram the tessellation stuff into core?)

Needs general testing, and still some TODOs:

• No "Click to Play"/play button; will start with a blank screen, click on it to start the movie
• Allow choosing between the canvas and WebGL backends
• Minimize GL state change calls
• Make common_tess::tessellate_shape return an Iterator
• WebGL2 support when available (VAO, MSAA settings, ...)

[kmeisthax]

👍 on adding a separate render common crate. The core crate is so large and unwieldy it alone takes a significant amount of compile time. AFAIK rustc parallelizes on a per-crate basis, so we should be pulling things out of core whenever possible.

[Dinnerbone]

I'd call common_tess gl_common as none of it will be reusable with wgpu. It assumes a lot about the pipeline, shaders and uniforms involved.

[Herschel]

I guess I don't follow what's different; wgpu would still need to use the tessellator, so there should be at least some common code. Currently it just spits out a mesh with a generic format, and it'd be up to the backend to transform that into its own format. If there are assumptions baked into common_tess, we should pull them out to make it generic. Maybe this involves removing the concept of Draw and simply returning a vertex array along with an associated fill type for each fill.

[Dinnerbone]

Here's what it looks like at the moment (big WIP) in wgpu: https://github.com/Dinnerbone/ruffle/blob/5df7cafd4ea940d091a902224bae03e58090c024/desktop/src/render.rs#L520

The overall structure is the same, I agree, but the actual "what it's doing" will vary quite a lot. The structures it creates, the data it fills those with - those will be different. We can of course have yet another intermediate layer between what's actually sent and what that method generates, but I think that's extra cost for nothing.

[Herschel]

I don't think there is necessarily any extra work:

1. If we make tessellate_shape work in a streaming way, there'd be no extra allocation, it'd be the same as grabbing the lyon buffer in each flush_draw (this is the "TODO, Make common_tess::tessellate_shape return an Iterator").
2. Make tessellate_shape generic over the vertex and index type <V, I>, so that you wouldn't even transform between vertex types, you just grab the data out of the lyon buffer.
3. Return the swf::Gradient etc. directly in tessellate_shape, and leave it up to the backend to transform it to its desired uniform format (common methods like common_tess::swf_matrix_to_gl_matrix can be used).

Ideally if we make improvements to the tessellator, all backends should benefit. For example, I know there are some issues with strokes being output in an incorrect order; if this is fixed, it'd be nice to just fix it in one place instead of having to futz about in each backend. Maybe this becomes less important because we may eventually remove webgl anyways.

[Dinnerbone]

I feel like a lot of that work should be done before it reaches this method, really. I started trying to pull that out when I worked on the drawing API; the intermediate stage represented here is the same as the output from that API.

[Justin-CB]

Clippy don't like this, apperantly.