Uncouple glyph storage from text processing

## What problem does this solve or what need does it fill?

I have a crate doing text rendering in a different way than Bevy does. Originally, I was reusing the Bevy text pipeline, it was really great. Later some changes forced me to make a copy of the entire `TextPipeline` and related classes, which added a lot of maintenance overhead, just because the way Bevy stored glyphs (one texture per font per size) was in my opinion quite wasteful, and I wanted a different glyph storage. Now that Bevy switched from ab to cosmic, I find myself once again copy-pasting and very lightly modifying the `TextPipeline` and other classes, just because of that storage decision. This is a lot of wasted time, while there's no real good reason other than lack of previous need why the glyph storage solution is intertwined with the text processing of Cosmic.

## What solution would you like?

Add an interface to decouple where/how glyphs as stored in textures, from the rest of the text processing (collecting glyphs, rasterizing them, layouting multi-line text, _etc._).

## What alternative(s) have you considered?

What I'm doing currently, which is copy/pasting `bevy_text` and doing some light modifications. This however invariably lead to subtle issues, which requires days of debugging to figure out why glyphs are not properly aligned _etc._. This works entirely duplicate what `bevy_text` authors already did.

## Additional context

I believe we should also really reconsider that pattern of creating one texture atlas per font per size. It's unlikely any app has more than a few fonts in use, and possibly some of them are used for a few words only (title, _etc._) which means we're wasting large atlas textures and force (in the absence of bindless) separate draw calls for no good reason, as there's no technical limitation I know of to packing different font families and sizes into the same atlas.

Start by reading Bevy's bevy_text TextPipeline and related glyph-storage classes, including the Cosmic-based text processing described in the issue. Trace where glyphs are collected, rasterized, laid out, and stored. Done means alternate texture storage can be used without copying the text pipeline, while existing text rendering behavior remains intact.

Written by the indexing model from the issue text.