Fix enum-variant class names that collide with a same-named type

[DenisovAV]

Problem

A data-carrying enum variant is rendered as a Dart class named {Variant}{Enum}. When that concatenation equals a real top-level type name, the generated file contains two declarations with the same name — a Dart compile error.

Concrete case (reduced from a real crate):

#[derive(uniffi::Record)]
pub struct FieldCondition { key: String }

#[derive(uniffi::Enum)]
pub enum Condition {
    Field { condition: FieldCondition },  // -> Dart class `FieldCondition`
}

The Field variant of Condition becomes class FieldCondition extends Condition, clashing with the FieldCondition record. dart analyze then reports duplicate_definition (and the FfiConverter's read dispatch calls .read on the wrong class). The same happens for a Named variant over a NamedVector type, etc.

Fix

Collect the top-level type names (records / enums / objects) and, only on collision, suffix the variant class with Variant (FieldConditionVariant). Non-colliding variants are unchanged, so existing generated APIs are untouched.

The name is produced by a single shared closure used both where the variant class is defined and where the enum's FfiConverter read dispatches to it — the two computed the name independently before, so fixing only the definition site left a dangling .read reference.

Test

Adds an enum_variant_collision fixture reproducing the clash (Condition::Field + record FieldCondition). It fails to compile without the fix (duplicate class) and round-trips with it. cargo test -p enum_variant_collision is green.

Note

Includes a small chore commit dropping a redundant & in a few format!/println! args — stable clippy 1.97+ added redundant reference in format! argument, which fails cargo clippy -- -D warnings on the current Testing CI for pre-existing code. Needed for green CI here; harmless to drop on rebase if it lands elsewhere first.

[chavic]

Nice work, thank you! One note for a possible follow-up, not for this PR: the reserved set does not contain the class names of other variants. Because of this, two variant classes from different enums can still collide, for example FieldA + Cond and Field + ACond. This case is rare, and the loop can cover it later.

[chavic]

The one failed check is the flaky dart_async timing test, which #157 has now fixed on main. I queued a re-run of the failed job, but it tests the original merge snapshot from before #157. If it fails again, please rebase on main to pick up the fix. Everything else is green and there are no conflicts.

[chavic]

@DenisovAV, thanks for the fix