fix(translator): trait member value comparison and adaptation validation

[AlessioGiacobbe]

Two trait-composition gaps:

• Trait constant/property conflicts were compared by pretty-printed source text: two traits declaring const int X = 1 + 1; and const int X = 2; (or defaults spelled [1, 2] vs array(1, 2)) were rejected as conflicting, while Zend compares evaluated values. Values are now compared by evaluation — with Zend's declaration-time int→float coercion for float-typed members — falling back to source-text equality only when a value cannot be evaluated at compile time. Different values, visibility, or types still conflict.
• Trait adaptations referencing nonexistent methods were silently ignored: use A { missing as g; } and use A, B { B::f insteadof A; } (with no B::f) both compiled — a typo in an adaptation did nothing. Every alias and precedence rule is now verified against the composed methods, with Zend's diagnostics; an unqualified alias is registered under every used trait, so its variants share one group satisfied by any match, and precedence rules also verify the named traits are actually used.

Verified against Zend 8.4.13; nested-trait aliasing covered.

Part of the split of #39.

[matyhtf]

Two invalid programs still compile.

1. traitIgnored stores a single rule under the loser Trait::method key. A later rule for the same loser overwrites the earlier rule, so not every preferred method is validated:

trait A { public function other(): void {} }
trait B { public function f(): void {} }
trait C { public function f(): void {} }
class X {
    use A, B, C {
        A::f insteadof B;
        C::f insteadof B;
    }
}

Zend reports A precedence rule was defined for A::f but this method does not exist; this PR compiles it. Preserve every precedence-rule record separately from (or as a list behind) the ignored-method lookup, and validate every record.

2. Trait constant identity short-circuits on ConstantDef::$value. Different enum classes with the same case name are both normalized to the same string and are incorrectly accepted:

enum E1 { case Value; }
enum E2 { case Value; }
trait T1 { const X = E1::Value; }
trait T2 { const X = E2::Value; }
class X { use T1, T2; }

Zend rejects these distinct case objects; this PR compiles them. Do not use the normalized case-name string as an identity proof. Retain/compare the enum class and case identity, and add positive coverage for the same enum case plus negative coverage for different enum classes.

[AlessioGiacobbe]

Both fixed, rebased on current master:

1. Precedence rules — every rule record is now preserved as a list behind the loser key (the isset()-based ignore lookup is unchanged), prepareTraitUse merges per-key instead of dropping earlier use clauses' rules, and validation iterates every record: your repro fails with Zend's exact wording (A precedence rule was defined for A::f but this method does not exist). Keeping all records also let me implement Zend's duplicate-exclusion rule ("Method of trait B was defined to be excluded multiple times" — probed), reported after the existence checks in Zend's order. One winner excluding several losers stays legal (probed).
2. Enum case identity — the trait-member value comparison no longer collapses cases to a scalar: the evaluation path returns a collision-proof (enum class)::(case) identity used only by the trait comparator (general constant folding untouched), and the premature value === value short-circuit — which treated every non-literal initializer as equal because they all share an empty compiled value — now defers to the evaluated comparison. All six probed combinations match Zend: same enum + same case compiles; different enums, same enum different cases, different backed enums with equal backing, and array-wrapped cases all reject.

17/17 focused tests green; sweep and full suite identical to base. One scope note: a case reached indirectly through another class constant still collapses to its scalar in this comparator — happy to cover that in a follow-up if you'd like it here.

[matyhtf]

Please rebase this branch onto the latest master; #45, #52, #59, #63, and #66 have now been merged.

The enum-case identity marker is still representable by user code. PHP strings are binary-safe, so the NUL prefix does not make this value collision-free:

enum E { case A; }
trait T1 { const X = E::A; }
trait T2 { const X = "\0enum-case\0e::A"; }
class C { use T1, T2; }

Zend rejects the composition because an enum-case object and a string are different values. This branch evaluates both definitions to the same marker string and may accept them.

Please use an internal typed identity value that PHP constant expressions cannot construct, with stable/interned identity for repeated references to the same enum case, and add the collision above as a negative regression test. Arrays containing enum cases must preserve the same distinction recursively.

[AlessioGiacobbe]

Rebased onto current master. The identity marker is no longer a string:

• Enum cases now evaluate (under identity semantics) to an interned compiler-internal object — EnumCaseIdentity::intern(enumClass, caseName), one singleton per (lowercased FQ enum, case-sensitive case name) pair. ConstExprEvaluator can only produce scalars, arrays and null from user constant expressions, so no user-spellable value can ever be === to an instance; interning makes === a stable identity for repeated references, and PHP's === on arrays compares elements with === again, so the distinction nests recursively.
• ENUM_CASE_IDENTITY_PREFIX and the NUL-marker code are gone.

Tests added (each first verified against Zend 8.4.13): the exact collision program from the review (E::A vs "\0enum-case\0e::A") now conflicts; [E::A, 1] in both traits composes; [E1::Value] vs [E2::Value] conflicts.