feat(rust): add #[fory(native)] option to use Rust native enum

[BaldDemian]

Why?

For #[derive(ForyUnion)] enum {...}, Fory decides if it is xlang union or Rust native enum based on its shape:

fory/rust/fory-derive/src/object/derive_enum.rs

Lines 795 to 808 in 7e9d416

	fn is_union_compatible_enum(data_enum: &DataEnum) -> bool {
	let has_data_variant = data_enum
	.variants
	.iter()
	.any(|v| !is_runtime_unknown_variant(v) && !matches!(v.fields, Fields::Unit));
	let all_variants_compatible = data_enum.variants.iter().all(|v| match &v.fields {
	_ if is_runtime_unknown_variant(v) => true,
	Fields::Unit => true,
	Fields::Unnamed(f) => f.unnamed.len() == 1,
	Fields::Named(f) => f.named.len() == 1,
	});
	has_data_variant && all_variants_compatible
	}

If all variants of the enum are unit or contain at most one field, e.g.

enum Event {
    #[fory(default)]
    Empty,
    Text(String),
    Code {
        value: i32,
    },
}

it is xlang union and requires a Unknown variant:

fory/rust/fory-derive/src/object/derive_union.rs

Lines 59 to 64 in 7e9d416

	if is_typed_adt_union(data_enum) && !data_enum.variants.iter().any(is_runtime_unknown_variant) {
	return Err(syn::Error::new(
	input.ident.span(),
	"ForyUnion typed ADT unions require a #[fory(unknown)] carrier with one UnknownCase field",
	));
	}

This brings inconvenience for users who only use serialization/deserialization inside Rust.

What does this PR do?

Add a #[fory(native)] option to allow users to use Rust native enum explicitly.

Related issues

Closes #4177.

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 or equivalent persisted links of the final clean AI review results from both fresh reviewers described in AI_POLICY.md, the Fory-guided reviewer and the independent general reviewer, on the current PR diff or current HEAD after the latest code changes.

Does this PR introduce any user-facing change?

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

Benchmark