fontique: enumerate system fonts via CoreText

[raiscui]

Use CTFontCollection::from_available_fonts to extract font file URLs and scan the unique paths.\n\nIf enumeration fails, fall back to the previous Library/Fonts scan.

[nicoburns]

What is the motivation behind this PR? And please could you run a performance comparison comparing the old and new approaches?

[raiscui]

Thanks for the question.

Motivation: on Apple platforms we previously populated system fonts by scanning Library/Fonts (via
NSSearchPathForDirectoriesInDomains(...)/Fonts/). That approach can miss a set of system/UI fonts
that are shipped as AssetsV2 (e.g. PingFang / SF),PingFang is macos system font for Chinese, which leads to incomplete system font coverage
and suboptimal fallback. This PR switches the CoreText backend to enumerate all available fonts via
CoreText, extract unique file URLs from the returned descriptors, and then reuse the existing scan
pipeline. The previous Library/Fonts scan remains as a fallback if CoreText enumeration fails or
returns empty.

Performance: I added a benchmark to track the one-time system-font initialization cost:
parley_bench/src/fontique_benches.rs → Fontique - system fonts init (CoreText).

Repro (macOS):
cargo +stable bench -p parley_bench --bench main -- solo -f 'Fontique*' -s 5

On my Apple M2 (macOS 15.7.2), the parent commit (4fd74d9, directory scan) is ~9.5 ms median and
this PR is ~25.8 ms median (5 samples), i.e. ~+16 ms one-time overhead. Given the improved font
coverage (notably system UI fonts), this seems like an acceptable tradeoff, make things right? I don't know how to optimize it for the time being.

[nicoburns]

This fixes #242. As such, I think we definitely ought to accept this PR.

[dfrg]

Does this capture the "hidden" system fonts, specifically San Francisco? If so, I'm +1 on this change.