Closes #50483 

## Findings

As reported in the original issue, emojis in SVG preview were not
rendering consistently with the editor.

The SVG renderer uses `usvg`/`resvg` for parsing and rendering SVG
files. The first problem was that emoji fonts were not rendering at all,
which was fixed by enabling the `raster_images` on `resvg`.

Beyond that it was observed that the default font fallback mechanism in
`usvg` searches through the font database alphabetically without
prioritizing emoji fonts. This caused emojis to sometimes render in
non-emoji fonts that happened to contain glyph mappings for those
characters.

For example, on Linux systems with the default
`uvsg::FontResolver::default_fallback_selector()`:
- The character ✅ would fall back to `FreeSerif` (monochrome)
- Instead of `Noto Color Emoji` (full color)

Log output showed the inconsistent behavior:
```
WARN  [usvg::text] Fallback from FreeSans to Noto Color Emoji.
WARN  [usvg::text] Fallback from FreeSans to FreeSerif.
WARN  [usvg::text] Fallback from FreeSans to Noto Color Emoji.
```

<img width="480" height="480" alt="Image"
src="https://github.com/user-attachments/assets/e065608f-a98b-4e67-9429-4aed16810c2c"
/>


This created a jarring inconsistency where the same emoji character
would render differently in:
- The editor (correct, using platform emoji fonts)
- SVG preview (incorrect, using arbitrary fallback fonts)
## Solution

If the specified font in SVG is available on the system, we should show
that. If not, we should fallback to what editors show today for that
emoji.

This PR implements emoji-aware font fallback that:

1. **Enabled `raster_images` build feature** to render emojis in SVG.
2. **Detects emoji characters** using Unicode emoji properties (via
`\p{Emoji}` regex pattern), consistent with how we check for emoji in
the Editor as well.
3. **Preserves user-specified fonts** by only intervening when the
default font resolver would use a non-emoji font for emoji characters

### Font Family Selection

I avoided completely reusing/rebuilding the logic for emoji font
selection used by the editor as `uvsg` internally does quite a bit of
the job and it felt like overcomplicating the solution. Instead using
hard coded platform specific font family names.
The hardcoded emoji font families are sourced from Zed's existing
platform-specific text rendering systems:

- **macOS**: `Apple Color Emoji`, `.AppleColorEmojiUI`  
Source:
https://github.com/zed-industries/zed/blob/db622edc8b26bd138c91027a02792a84c083acbf/crates/gpui_macos/src/text_system.rs#L353-L359
- **Linux/FreeBSD**: `Noto Color Emoji`, `Emoji One`  
Source:
https://github.com/zed-industries/zed/blob/db622edc8b26bd138c91027a02792a84c083acbf/crates/gpui_wgpu/src/cosmic_text_system.rs#L642-L646
- **Windows**: `Segoe UI Emoji`, `Segoe UI Symbol`  
  Source: Standard Windows emoji font stack

These match the fonts the editor uses for emoji rendering on each
platform.
To break down further into the similarity and differences in the emoji
font resolution:
**Similarities:**
- Both now use the regex based emoji detection logic
- Both prioritize the same platform-specific emoji font families
- Both support color emoji rendering
**Differences:**
- **Editor**: Uses platform-native text shaping (CoreText on macOS,
DirectWrite on Windows, cosmic-text on Linux) which handles fallback
automatically
- **SVG**: Uses custom fallback selector that explicitly queries emoji
fonts first, then falls back to default usvg behavior
## Testing

- Added unit tests for `is_emoji_character` in `util` crate
- Tested emoji detection for various Unicode characters
- [ ] Verified platform-specific font lists compile correctly (Only
linux done)
- [ ] Manual testing with SVG files containing emojis on all platforms
(Only linux done)

Release Notes:

- Fixed SVG preview to render emojis consistently with the editor by
prioritizing platform-specific color emoji fonts

---------

Signed-off-by: Alan P John <alanpjohn@outlook.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>