Improve emoji rendering quality - need better color emoji support

[GrandpaEJ]

Current Status

Basic emoji rendering is now functional (implemented in #12), but the quality needs improvement.

Problem

Currently, emojis are rendered using:

1. Fallback geometric shapes - Simple colored circles/shapes based on emoji category
2. Basic font loading - Attempts to load system emoji fonts but doesn't properly extract color glyphs
3. Limited color support - Cannot render true color emojis from fonts like Noto Color Emoji

What We Have

✅ Automatic emoji detection in text
✅ ZWJ sequence parsing (families, professions, etc.)
✅ Skin tone modifier support
✅ Fallback rendering system
✅ Emoji caching

What We Need

High Priority

• Proper COLR/CPAL table parsing - Extract vector color emoji data from OpenType fonts
• CBDT/CBLC bitmap extraction - Render bitmap color emojis (used by Noto Color Emoji)
• sbix format support - Apple's bitmap emoji format
• Better glyph rendering - Actually render emoji glyphs instead of fallback shapes

Medium Priority

• SVG-in-OpenType support - Some fonts embed SVG for emojis
• Emoji font library - Dedicated library for parsing color emoji fonts
• Multi-codepoint glyph lookup - Better handling of complex emoji sequences
• Emoji atlas generation - Pre-render common emojis for performance

Research Needed

Need to investigate:

1. Go libraries for parsing OpenType COLR/CPAL tables
2. Bitmap extraction from font files
3. How other Go graphics libraries handle color emojis
4. Potential use of external tools (like libraqm, harfbuzz with color support)

Current Workaround

Users can:

• Use the fallback rendering (category-based colored shapes)
• Disable emoji rendering with SetEnableAutoEmoji(false)
• Provide pre-rendered emoji images

References

• OpenType COLR/CPAL spec: https://docs.microsoft.com/en-us/typography/opentype/spec/colr
• CBDT/CBLC spec: https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt
• Noto Color Emoji: https://github.com/googlefonts/noto-emoji