Fuzz the #[cube] macro

[LucaCappelletti94]

A fuzzer feeds a function huge amounts of random input to find inputs that make it crash. This PR adds one for the #[cube] procedural macro, plus the small refactor needed to make it possible.

It is a preliminary step, building towards a differential fuzzer that runs the same kernel through the CPU and GPU backends and compares results to catch miscompilations. That oracle only means anything once the front end is solid, so #[cube] has to be stable under fuzzing first. The execution differential comes in a future PR.

A cargo fuzz target is an ordinary binary, and Rust does not let one call into a proc-macro = true crate, so the macro logic has been moved into a new normal library, cubecl-macros-core.

The target (fuzz/cube_macro) feeds random source text to cube_impl and checks it never panics. The macro should return a syn::Error (rendered as a spanned compile_error!) for anything it cannot handle, never panic: a panicking proc macro aborts the user's build with an opaque, span-less message and is handled poorly by rust-analyzer.

cargo +nightly fuzz run cube_macro -- -dict=fuzz/cube_macro.dict

A dictionary of cube and Rust tokens is included to reach the macro internals quickly.

A short run already finds real (and arguably trivial) issues: the macro has a proper error path but a few spots bypass it and panic.

• parse/kernel.rs: a trait-object kernel argument hits unimplemented!("Trait objects are not allowed for kernel args"), a valid rejection done as a panic. Reproducer: fn f(x: dyn Foo) {}.
• parse/expression.rs: calling an indexed expression like a[0]() hits a leftover panic! debug guard, though the surrounding match already has a fallthrough arm. Reproducer: fn f() { a[0](); }.
• parse/expression.rs: a const-folding path calls .unwrap() on as_const, assuming anything const can be evaluated as const. An actual logic bug, not just a panic that should be an error.

Fixes are left for follow-up so they can be reviewed separately.