Fast specialized CPU glyph rasterization

Nobody has claimed this yet.

https://github.com/emilk/egui/issues/8093 notes that glyph rasterization in egui is slower using `skrifa`+`vello_cpu` compared to the old rendering using `ab_glyph`. To some extent that is expected and reflects that `skrifa`+`vello_cpu` renders glyphs at higher quality.

Nevertheless, `vello_cpu` is a generalized rasterisation pipeline that is slower than it could be for the task of rendering glyph outlines, and we may want to consider creating an optimised pipeline specifically for glyph rasterization.

I am assuming that this rasterizer would be only for regular "outline" glyphs and COLR glyphs would still use the regular `vello_cpu` pipeline. We may also want to consider whether we could/should support subpixel rendering.

### Prior Art

Potential sources of inspiration for such a renderer

- Raph's https://github.com/raphlinus/font-rs ([blog post](https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445))
- Chad's https://github.com/dfrg/zeno (used in swash)
- Behdad's https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-raster-draw.cc ([zulip thread](https://xi.zulipchat.com/#narrow/channel/296640-font-tech/topic/hb-raster.3A.20a.20new.20CPU.20rasterizer/with/575467244))
- FreeType's rasterizer
- Vello CPU

Start by profiling the existing glyph path in vello_cpu and comparing it with the cited font-rs, zeno, HarfBuzz, and FreeType rasterizers. Define the scope for outline glyphs versus COLR glyphs and decide whether subpixel rendering is required. Done means an agreed specialized pipeline design with performance and quality criteria; the issue names no files or tests.

Written by the indexing model from the issue text.