Optimizing the Painter Backend for Web and Binary Size

[M-Adoo]

Currently, the wgpu backend is only web-ready if it supports WebGPU. This is due to our usage of certain WebGL2 features that are not universally supported.

Given the limited adoption of WebGPU (only enabled by default in Chrome on Windows/MacOS), we can't claim full support for the web platform yet.

To fully support the web platform, our first step should be to ensure the wgpu backend works with WebGL2. This doesn't seem to be a difficult task, but it may increase the binary size. For instance, when I tested the counter example with normal optimization level, I found:

1. The WASM size is 4.7M with the wgpu backend and WebGL2 enabled.
2. The WASM size is 3.0M with the wgpu backend and WebGL2 disabled.

The main contributors to this size are:

1. Heavy dependencies like wgpu and winit.
2. Embedded resources in the binary, such as font files and icons.
3. Numerous small dependencies.
4. Extensive use of generics in ribir.

Ideally, we'd like to achieve a binary size in the KB range for simple apps in the future, which means generating WASM files smaller than 1M without gzip. While issues 2-4 can be resolved, winit (less than 200KB) might be acceptable, but wgpu could prevent us from reaching this goal.

There are two potential solutions:

1. We could leverage our abstract GPUBackend (which wgpu is based on) to implement a lightweight WebGL2 backend. However, maintaining two GPU backends long-term is not cost-effective.
2. We could implement a painter backend that ports to the platform's native 2D render engine, regardless of whether it uses GPU or CPU rendering. This would be simple to implement and result in a smaller binary size. It could also serve as a compatibility solution for platforms that don't support wgpu.

Our final decision is to:

1. Extend the wgpu backend implementation to cover WebGL2, enabling its use on the web platform. Feat/webgl support #578
2. Implement a Path Backend that ports to the platform's native 2D render engine, initially only CanvasContext2d for the web platform.

Users can then choose how to use the painter backends:

1. Use both wgpu and Path backends for optimal performance and compatibility, albeit with a larger binary size.
2. Use only the wgpu backend for better performance but a slightly larger binary size.
3. Use only the Path backend for the smallest binary size and good compatibility, though performance may be suboptimal in complex scenes.