fix(scc): catch panics at the scc_compile FFI boundary

[ExylonDerMaster]

scc_compile is invoked in-process by RED4ext, running directly inside the game's executable rather than through the standalone scc.exe. In that context a panic anywhere in the compiler — for example one triggered by a script that doesn't match the current game version — unwound straight across the extern "C" boundary into the native host. That's undefined behavior, and for us it crashed the whole game instead of just failing the compilation with an error message.

This PR:

1. Wraps scc_compile in catch_unwind so a compiler panic becomes a normal SccResult::Error instead of crossing the FFI boundary.
2. Removes duplicate_to_stdout() from setup_logger() — running in-process inside a GUI executable means there's no console/stdout handle, so that write was failing, and flexi_logger's own error-reporting path (which also goes through stdout) failed right after it. That's what was actually causing flexi_logger itself to panic on every in-process compile — the very panic that motivated fix Add a script compiler #1.
3. Adds a local #![allow(unused_parens)] in core/src/definition.rs and core/src/bundle.rs — newer rustc misattributes a false-positive "unnecessary parentheses" lint onto the #[bitfield]-annotated fields there, and the workspace denies all warnings, so this was otherwise breaking the build.

Tested by rebuilding scc_lib.dll and confirming in-game: the flexi_logger panic is now caught and reported cleanly instead of crashing Cyberpunk 2077, and normal compile errors/successes are reported correctly via RED4ext's logs.

[ExylonDerMaster]

Heads up on the CI failures here (cargo build/cargo test, cargo clippy, and the macOS build) — they look unrelated to this change:

• The last successful CI run on 0.5.x was over a year ago (2025-08-28), so the branch hasn't been re-tested against newer Rust/clippy/runner versions since.
• I checked out the unmodified 0.5.x tip (e419382) locally and reproduced the same clippy failures without any of this PR's changes: the "unnecessary parentheses around type" errors on the #[bitfield] fields (which commit 2 here fixes), and a separate redundant reference in format! argument in scc/cli/src/opts.rs:33, a file this PR doesn't touch.
• The macOS job fails at the zip-packaging step (Could not create output file .../merge-macos.zip), also unrelated to any Rust source change.
• The opts::test::standard::... test failures don't reproduce for me running that suite in isolation against the unmodified base commit (6146/6146 passing), so they look environment- or ordering-dependent rather than caused by this diff.

So this looks like pre-existing toolchain drift on a branch that hasn't had CI run in a while, not a regression from this PR. Happy to help fix the unrelated clippy issue and macOS packaging step in a separate PR if that's useful.