Add emitTo to generated event bindings

[johncarmack1984]

Closes #187.

Note: the first commit here is the snapshot suite from #248, kept so the second commit's fixture diff shows exactly what emitTo changes in the generated output. If #248 lands first I'll rebase this down to the emitTo commit alone.

What changed

• add emitTo(target, payload) to generated event objects, on both the global form (events.myEvent.emitTo("main", payload)) and the target-scoped form (events.myEvent(webview).emitTo("main", payload)), for TypeScript and JSDoc
• add an EventEmitTo<T> runtime type mirroring EventEmit<T>'s null-payload handling (unit-payload events take only the target argument)
• register EventEmitTo in RESERVED_NDT_NAMES, and also add the previously missing EventEmit, so user types with those names get renamed instead of colliding with the runtime
• regenerate the example bindings and snapshot fixtures

Why

emit broadcasts to all targets; there was no generated way to reach emitTo's targeted delivery, so scoping an event to one window meant dropping back to the untyped API.

Validation

• cargo test --all-features (the snapshot suite caught the runtime change in every event-bearing scenario; fixtures regenerated)
• cargo clippy --all-features --all-targets (no warnings), cargo fmt --check
• tsc --noEmit --strict on the regenerated TypeScript bindings (flat, namespaces, and plugin variants) against @tauri-apps/api 2.11.1 — emitTo and the EventTarget type check out on the module-level API and the Window/Webview classes
• JSDoc bindings produce the same five pre-existing --checkJs --strict diagnostics before and after — none introduced

Notes

The custom-plugin example's committed bindings.ts had drifted behind main (it still had the old single-generic makeEvent<T>); the regeneration here folds that catch-up in with the emitTo change.