feat(rust): make fory-derive generated code use exported api in fory rust lib

[chaokunyang]

Why?

Rust users should be able to depend on the user-facing fory crate only and still use derive-generated serializers, row derives, trait-object registration, and public runtime types. The derive output also needs to keep working when the fory facade is renamed in Cargo.toml, while lower-level integrations can still use fory-core directly.

What does this PR do?

• Re-exports the Rust derive macros and public runtime types from fory, and exposes a hidden fory::__private runtime root for generated code.
• Adds proc-macro-crate based runtime-root resolution in fory-derive, preferring the fory facade and falling back to fory-core for direct lower-level use.
• Updates generated object, enum, union, row, skip, and trait-object code to emit paths through the resolved runtime root instead of hard-coded ::fory_core paths.
• Makes fory-core macro exports hygienic through $crate, including trait-object registration helpers.
• Adds Rust API test crates for facade-only and renamed-facade dependencies, covering object derives, row derives, trait objects, unions/enums, manual serializers, and rejected #[fory(crate = ...)] usage.
• Updates Rust docs and agent guidance to describe fory as the normal application dependency and fory-core/fory-derive as lower-level crates.

Related issues

Closes #3755

AI Contribution Checklist

• Substantial AI assistance was used in this PR: yes / no
• If yes, I included a completed AI Contribution Checklist in this PR description and the required AI Usage Disclosure.
• If yes, my PR description includes the required ai_review summary and screenshot evidence of the final clean AI review results from both fresh reviewers on the current PR diff or current HEAD after the latest code changes.

Does this PR introduce any user-facing change?

Yes. Rust applications can use derive macros and generated code through the fory facade crate without declaring direct fory-core or fory-derive dependencies.

• Does this PR introduce any public API change?
• Does this PR introduce any binary protocol compatibility change?

Benchmark

Not applicable; this is a Rust API/export and derive-path change.