Centralise 2D rendering context managements

[Desplandis]

Description

This PR introduces a new CanvasUtils module that centralises the creation and management of 2D rendering contexts. It provides three helper functions covering the main usage patterns in the codebase:

• Dedicated long-lived canvas (e.g. for canvas textures)
• A shared render-only canvas for short-lived synchronous work
• A shared render-and-read canvas for short-lived synchronous work that requires pixel reads

The utilities intentionally return rendering contexts rather than canvases. This avoids a browser behavior where calling getContext() multiple times with different initialization options always returns the first-created context, ignoring subsequent parameters. This issue already existed in the codebase before this PR.

As part of this refactor, I also removed several unnecessary willReadFrequently context initialisations. Those contexts never performed read operations, so dropping the flag improves performance (20% to 6% CPU usage in a MVT example, hard to quantify without proper benchmarking...).

Additionally, icon tinting has been reworked. The previous per-pixel replaceWhitePxl implementation as been replaced with a canvas compositing approach (multiply & destination-in). This solution is simpler, faster since this is canvas-only, and allows removing Renderer/Color.js.