gc: add unsafe_empty_trace parity and collector-agnostic helper paths

[Flamki]

Part of #76 and #63.

This PR adds missing unsafe_empty_trace! parity and removes helper macro coupling to mark_sweep-specific paths.

What changed

• Added crate-level trace API re-export module: oscars::gc_trace.
• Updated helper macros in mark_sweep::trace:
  • empty_trace! now resolves through $crate::gc_trace.
  • custom_trace! now resolves through $crate::gc_trace.
  • Added new unsafe_empty_trace! macro.
• Updated oscars_derive generated trait paths from ::oscars::mark_sweep::* to ::oscars::gc_trace::*.
• Updated arena2 trace re-export comment to reflect collector-agnostic helper path behavior.
• Added focused tests in both collectors:
  • unsafe_empty_trace_runs_finalize in mark_sweep
  • unsafe_empty_trace_runs_finalize in mark_sweep_arena2

Why

• #63 still tracks unsafe_empty_trace! as an open parity gap.
• mark_sweep_arena2/trace.rs previously called out brittle hardcoded helper paths.
• This keeps helper behavior identical while decoupling path assumptions from one collector module.

Scope

• trace helper macros, derive path plumbing, and tests only
• no allocator policy changes
• no collector algorithm changes
• no Boa integration wiring

Validation

• cargo fmt --all -- --check
• cargo test --workspace -q
• cargo clippy --workspace --all-features --all-targets -q
• cargo +nightly miri test -p oscars --all-features -q

[nekevss]

overall looking good. Just one major thing that I noticed.

[nekevss]

issue: we shouldn't reexport these items from gc_trace

Eventually we should resolve export paths, but as it stands, the trace functionality is very specific to the mark sweep gc.

[Flamki]

Thanks for the review — agreed, and fixed.

I removed the gc_trace re-export from lib.rs and switched macro/derive paths back to explicit mark_sweep trace exports.

unsafe_empty_trace! parity is still included, and tests remain in place for both collectors.

I also reran fmt, tests, clippy, and miri locally; all green.