Taking the address of a virtual method through a receiver
(`M := @Obj.Method`) stored the statically-resolved declared-type
method address as the Code half of the (Code, Data) method pointer.
A later call through M therefore always ran the declared type's method,
ignoring the receiver's dynamic override — unlike a direct `Obj.Method()`
call, which dispatches through the vtable.
Resolve the Code half through the instance's vtable when the method is
virtual/override (VTableSlot >= 0): load the vptr from the object,
index slot (VTableSlot + 1)*8 (slot 0 is typeinfo), and store the
resulting code pointer. Non-virtual methods keep the static label.
Both the QBE and x86-64 backends had the same defect; the native side
fixes it at both the variable- and field-destination assignment sites.
Additionally fixes a pre-existing native-backend bug this change exposed:
EmitClassSection re-asserts FSymTable.DefineOwningUnit to the unit being
emitted before every FindType. Resolving an earlier class in the loop
(its parent/field/method types via ClassSymName -> Lookup -> the
uses-chain walk) could leave DefineOwningUnit pointing at a dependency
unit; FindType for one of this unit's own implementation-section
(IsImplPrivate) classes was then suppressed by Lookup's cross-unit-leak
guard and returned nil, so the class was skipped and its typeinfo /
vtable / _FieldCleanup were never emitted. The dangling
`typeinfo_<Unit>_<Class>` reference (e.g. a metaclass value passed to
RegisterTest from the init block) then bound to a garbage address,
producing a layout-sensitive out-of-range-metaclass crash at runtime.
Tests: an IR-level assertion that the capture no longer stores the
static method label, plus two e2e cases (variable and field
destination) asserting the override runs on every backend.
c32bc73f2c