wasm-interpreter: register a monospace face at startup

[thelipe7]

Problem

Styled text's Code style asks for GenericFamily::Monospace directly
(internal/core/textlayout/sharedparley/shaping.rs:201). On a platform with no
system fonts to query — wasm, nto — the embedded set covers SansSerif,
SystemUi and UiSansSerif and nothing else, so that request resolves to no
family at all and the code span renders in the proportional face.

A snippet author hits this in any browser preview, and has no way to fix it: the
font has to come from somewhere in the binary.

Change

The obvious fix — registering a monospace face in create_collection — puts a
programming font in every application compiled for wasm, and most never draw
code. So create_collection deliberately doesn't do it.

Instead, i-slint-common gains register_monospace_font(), which nothing in the
core calls, and the wasm interpreter calls it from init(). The interpreter is
where snippets it didn't write get rendered, so it is the binary that should
carry the font.

Measured on the printerdemo wasm release build:

	bytes
master	9,821,060
this PR	9,821,101 (+41)
registering it in create_collection instead	9,954,675 (+133,615)

The 41 bytes are symbol noise: the linker drops the uncalled function along with
the font it embeds. The interpreter carries the 133 KB, 0.9% of its 14.3 MB.

Source Code Pro is already vendored for the LSP, so this adds no new third-party
dependency.

Validation

• cargo test -p i-slint-common --all-features — two tests. The monospace one
  asserts the generics resolve to nothing before register_monospace_font
  runs, so moving the font back into the shared collection fails the test rather
  than passing silently.
• cargo check -p slint-wasm-interpreter --target wasm32-unknown-unknown,
  cargo test -p i-slint-core.
• In a browser, against a wasm-pack --release build: a StyledText code span
  renders monospaced, and an unknown family still falls back to the sans.

Notes for review

• Source Code Pro Medium is a single weight. Bold code renders at Medium
  rather than a real bold. A variable mono would fix that at roughly 3–5× the
  bytes. Happy to swap if you'd prefer the fidelity over the size.
• The LSP's wasm preview has the same defect and would want the same call.
  Left out here so this PR proposes one shape in one place; happy to follow up.
• A plain Slint application compiled for wasm still renders code spans
  proportional. That is the deliberate trade above — it seemed wrong to charge
  every application for a font most don't use. Say the word if you'd rather
  cover them too.