toolkit: a system symbol is a stencil, not a photograph

[tannevaled]

A platform's own symbols arrive as pictures whose alpha is the shape and whose colour means nothing — what a platform calls a template image. The toolkit could take one only as an Image, which paints the pixels as they are: a black glyph that disappears on a dark card and never picks up the accent colour when its cell is selected. The alternatives were to rasterise the artwork a second time, or to blit it beside the widget by hand — and hand-blitting beside a widget is exactly what a consumer's "no hand-drawn UI" rule forbids.

StencilIcon(pix, w, h) reads the alpha and takes the colour from the caller, which makes it an IconFunc like every stock DrawIcon***: it drops into an IconCell, a TreeTableNode, or anywhere else that draws one, and follows the theme and the selection for free.

• The tinted copy is kept until the ink changes, so a grid redrawing every frame tints once, not once a frame.
• The source is neither modified nor retained beyond the drawer.
• The picture keeps its aspect ratio inside its box, centred: a system symbol is rarely square, and stretching one is what makes it look like somebody else's icon.
• An ink that is itself see-through thins the stencil rather than replacing its coverage.

Tests use a source whose own colours are red and blue on purpose, so anything reading them instead of the ink shows up: a 40×10 picture asserted not to come out square in a square box, the source asserted byte-for-byte unmodified, a half-transparent ink asserted to draw a different picture from an opaque one, and the result asserted identical on a back end without the image primitive — which draws it a pixel at a time, since that primitive is a speed-up and not a requirement.

Coverage stays at 100.0%.