Abstract glyph drawing logic as Draw trait

[EHfive]

Note

This is separated from #185 for easier review.

The trait contains only one method, draw_line, which is going to be implemented by glyph rendering backend like swash to scale & rasterize inputed glyphs and draw pixels of them.

This make it easier to implement other rendering backend, and allows switching rendering backend at runtime.

The original code of glyph rendering for swash is moved into Draw.

And add draw_with method to Buffer and Edit interfaces to draw with glyph rendering backend that implemented Draw trait. The original glyph drawing part using swash in buffer and editor is also migrated to using Draw.

---

I am thinking we could also deprecate swash specific draw methods in Buffer and Edit to use draw_with instead. Or just modify the interface of draw.

[notgull]

I think it would be better to just implement no_std support for Swash than to add the complexity of pluggable drawing backends

[EHfive]

@notgull
Some benefits for abstracting Draw trait.

• There was 2 copies of swash rendering code in Buffer and Editor, this helps to make the code be more organized.
• From SwashCache user's perspective, the draw and draw_with is the same for calling except the method name.
• If we decide to make Draw public(as it currently is), external crates are allowed to extend Buffer and Edit with their own glyph rendering backend.

Regarding no_std, I am currently in needs of no_std capability for my own hobby project and I found it easier for me to work on crates that are already no_std.

edit: I have revisited the code of swash and I found it's pretty easy to make it no_std, which makes #185 unnecessary for no_std once your work have done. But the points above still applies and I can still make the code of #185 as an extension crate to cosmic-text even it does not getting merged eventually.