feat(text): shadows for laid-out text, one coverage surface per paragraph

[sidorares]

drawGlyphs now consults the shadow state, so text drawn through a
TextLayout casts a shadow exactly as fillText does. It was the one text
path that ignored it — 8.1.0 wired _shadowed into seven drawing operations
and drawGlyphs was not among them — so the feature was missing exactly
where a drawing wraps, which is where a paragraph has to go through
layout() in the first place.

ctx.shadowBlur = 8;
ctx.shadowColor = '#000';
ctx.fillText('one line', x, y);   // shadow, before and after
layout.draw(ctx, x, y);           // shadow only after this

Rendered by this branch, headless into a pixmap: the same specimen with
the glyph-path shadow suppressed, then with it. The headings are fillText,
which was shadowed already.

How

• One coverage surface per call, not one per line. The runs already
  carry their own baselines, so they all go into the same padded a8
  surface and one blur, the same way they already go into one glyph
  composite. A paragraph whose spans change colour is drawn as several
  calls and casts a shadow per call — as consecutive fillTexts would.
• No re-shaping. _shadowOfText shapes the string again to size its
  surface; the layout case is handed its runs, so it measures them
  directly. New positionedRunsInk in lib/text/glyphs.js is the run-shaped
  counterpart of the context's _shapedInk.
• Cached on the runs, not on a string. The key is each run's identity —
  a shaped run is immutable and a layout keeps the ones its lines are made
  of, so a small integer per object names its glyphs at O runs rather than
  O glyphs — plus the run positions relative to the first. Two paragraphs
  of the same text at different widths therefore key differently, and
  re-drawing one layout anywhere on the target is a lookup and a composite.
  Runs rebuilt every frame have nothing stable to key on and rebuild, which
  is the honest answer.
• Over maxPixels the shadow falls back to the clipped, uncached path,
  sized to the part that can actually be seen — the same escape the
  fillText path takes.

Tests

test/shadow.test.js grows a suite against the pure-JS X server: the same
string drawn through fillText and through layout() produces the same
amount of shadow, every line of a wrapped paragraph is shadowed, the
transform carries the shadow with the text, a wrapped paragraph is one
retained surface reused across draws while another width is a second, and a
transparent shadowColor still does no work at all. The first three fail on
master.

Docs

docs/context-2d.md lists drawGlyphs among the shadowed operations and
describes the layout cache and the per-call rule; docs/text.md says it on
both TextLayout.draw and the glyph-run contract.

Closes #283