Migrate away from unmaintained proc-macro-error crate

FYI I used Claude Code to help me submit this issue.

Context

yew-macro depends on proc-macro-error 1.x, which is flagged by RustSec as unmaintained:

• RUSTSEC-2024-0370 — proc-macro-error 1.0.4 unmaintained (https://rustsec.org/advisories/RUSTSEC-2024-0370.html)

This is already tracked in #3765 (closed, pointing at #3752) and #3752 (open, stalled since 2024-12).

Why I'm opening a new issue rather than reviving #3752

PR #3752 swaps proc-macro-error → proc-macro-error2. Since that PR was written, the fork has also been flagged:

• RUSTSEC-2026-0173 — proc-macro-error2 2.0.1 unmaintained (the maintained fork is now itself unmaintained)

So merging #3752 as-is would close one advisory by opening another. The underlying choice — which crate should yew-macro use for proc-macro diagnostics? — hasn't been resolved, and I don't want to put work into a migration without a maintainer's preference on record.

Replacement options

The RUSTSEC advisory suggests two actively-maintained replacements:

1. proc-macro2-diagnostics — Closer API model to proc-macro-error's Diagnostic type and emit_as_*_tokens() pattern. Likely the smaller diff: entry-point attributes go away, abort!/emit_error! sites convert to Diagnostic::spanned(...).emit_as_item_tokens() or similar. No change to the Result-vs-panic control flow.

2. manyhow — Bigger API shift: proc-macro entry points return manyhow::Result<TokenStream> instead of relying on a wrapping #[proc_macro_error] attribute. Cleaner long-term, but a much larger refactor across every abort! callsite.

Both crates are actively maintained and free of RustSec advisories at the time of writing.

Ask

Before anyone (myself included) opens a PR, a quick steer from a maintainer:

• Is yew-macro open to migrating off proc-macro-error at all?
• If yes, preference between proc-macro2-diagnostics (smaller diff, preserves current control flow) and manyhow (bigger refactor, cleaner end state)?

Happy to take the PR on once there's direction. I'd also suggest closing #3752 in favour of whichever path is chosen, so future contributors don't land on the same dead-end swap.