feat: Add support to warp (deform) SpriteComponent rendering via a grid

[adario]

Description

Adds the ability to warp (deform) the rendering of a SpriteComponent via a grid of normalised
source (UV) and destination positions, similarly to SpriteKit's SKWarpGeometryGrid.

• New immutable WarpGrid (exported from components.dart): columns x rows cells, with
  normalised source and destination positions for each of the (columns + 1) * (rows + 1)
  vertices, stored in row-major order from the top-left corner (y pointing down, following
  Flame's conventions rather than SpriteKit's). Source positions are UVs relative to the
  sprite's source rectangle (not to the whole image), destination positions are fractions of the
  component's size (values outside 0..1 are valid). The grid never stores pixels: positions are
  converted to texture and component coordinates only when rendering, so the same grid keeps
  working when the component's size or sprite change.
• New WarpInterpolation enum:
  • bilinear (default) interpolates each cell independently.
  • catmullRom interpolates across cells with Catmull-Rom splines, passing through every
    vertex, for smoother warps.
• New HasWarpGrid mixin on SpriteComponent, adding the warpGrid and warpInterpolation
  properties It works with any SpriteComponent subclass, and with no grid the sprite is rendered
  as usual (drawImageRect).
• SpriteComponent.render now delegates to a new protected renderSprite method,
  which the mixin overrides (render is @mustCallSuper). The default implementation renders
  the sprite exactly as before.
• New WarpEffect (exported from effects.dart) to animate grids, similarly to SpriteKit's
  SKAction.warp(to:duration:): WarpEffect.by moves destination (and optionally source)
  positions by per-vertex offsets, WarpEffect.to moves both source and destination positions
  to those of another grid with the same dimensions (starting from an identity grid if the target
  has none). Like the other built-in effects it applies incremental changes, so several warp
  effects, and drags, can act on the same grid. It targets the new WarpGridProvider interface,
  which HasWarpGrid implements.

Each cell is subdivided into 4x4 sub-cells (a fixed subdivision level of 2, like SpriteKit's
default) and the sprite is drawn as a textured mesh with Canvas.drawVertices and an
ImageShader. The mesh, vertices and shader are cached per component and only rebuilt when the
grid, interpolation, sprite region, size or image change, so components sharing a Sprite can
each have their own warp. Warping only affects rendering: size, hit testing and collisions are
unchanged.

Workarounds for engine issues found while testing on macOS, iOS, Android (emulator) and web
(CanvasKit and skwasm), documented in the code:

• Impeller ignores the paint's color filter in drawVertices: when a color filter is set (e.g.
  tint, hue, ColorEffect) it is applied through a saveLayer, on every backend for
  consistency.
• Impeller crashes with some drawVertices blend modes (e.g. BlendMode.dst): the blend mode
  argument (which only combines vertex colors, not used here) is always srcOver, and the
  paint's blend mode is applied as usual.
• On CanvasKit, ImageShader.dispose() also disposes its image: the shader is never disposed,
  only dereferenced (on removal, when the sprite changes, or when the grid is removed), so that
  the shared sprite image is left alone. Dropping it when the sprite changes also avoids keeping
  an image alive after it is released from the Images cache.
• Texture coordinates are offset by -1/1024 texel, so that pixels sampling exactly between two
  texels (non-integer scales with nearest filtering) round the same way on every triangle, like
  drawImageRect, instead of showing 1-texel steps along the triangles' edges.

Tests cover the grid, the mesh builder (both interpolations), the component (identity grids
render like drawImageRect, including spritesheet regions, bleed, opacity, color filters and
non-integer scales; caching; sharing sprites; image eviction), the effect (relative, absolute,
reversed, combined, sequences, errors) and two golden files.

The new Sprite Warp example in the Sprites section shows two SpriteComponents with the
HasWarpGrid mixin that share the same sprite and the same WarpGrid: the left one uses
WarpInterpolation.bilinear, the right one WarpInterpolation.catmullRom. The left sprite has
a draggable handle on each vertex, connected by grid lines: dragging a handle moves the vertex's
destination position, and the right sprite mirrors the change.

Knobs:

• Grid Size: the number of cells per side (3 to 8, 4 by default); changing it starts over with
  an undistorted grid.
• Image: switches between a few sprites from the examples' assets, keeping the current warp.
• Animate: waves the grid back and forth with an infinite WarpEffect.by; since the effect is
  incremental, the handles can still be dragged while it runs.
• Reset: a button that resets the grid to the identity, like a double tap on the game; both are
  disabled while the animation runs. Since Widgetbook has no button knob, a small custom
  ButtonKnob is added to the examples' commons.

Note: the golden files were generated on macOS and may need to be regenerated on Linux.

Checklist

• I have followed the Contributor Guide when preparing my PR.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• I have updated/added relevant examples in examples or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.

Related Issues

Closes #4104