Fix cross-module class extends under -shared: inline dlsym resolution + decl-printer fixes

[ASDAlexander77]

Stacked on #276 (base branch is fix/crt-assert-report-mode) — merge #276 first, then this retargets to main automatically.

Summary

Makes a derived class extending a base from a dynamically imported module (-shared, real DLL boundary) work end-to-end. All six formerly disabled tests — test-{compile,jit}-shared-export-import-class-extends{,-multilevel,-implements-diamond} — now pass and are enabled.

Implements exactly the recommendation from docs/cross-module-dynamic-import-instanceof-design.md (§9, written after the previous session's three reverted attempts): a dedicated, self-contained resolution path with zero interaction with fullNameGlobalsMap scoping. Three co-operating fixes, each exposing the next once the previous error stopped masking it:

1. ClassMethodAccess inline dlsym fallback (MLIRGenImpl.h): a dynamic-import class member with neither a locally defined FuncOp (bodyless declarations are now explicitly excluded — they lower to unlinkable external references) nor a registered dlsym-global resolves in place via SearchForAddressOfSymbolOp + cast. No global registration at all — valid in both discovery and real passes by construction. This fixed the M.Animal..instanceOf can't be resolved error and cross-module super.method(...) calls generally.

2. Vtable slots owned by a dynamic-import base resolve at runtime (MLIRGenClasses.cpp): the extends-recursive vtable contains slots for inherited members (incl. the base's .rtti/.size statics under ADD_STATIC_MEMBERS_TO_VTABLE) whose symbols live in the DLL — a constant SymbolRefOp to those was a hard link error (lld: undefined symbol: M.Animal..size referenced by .data). Ownership is determined structurally (walk self + transitive bases, exact symbol match). GlobalOpLowering already routes such initializers through __cctor; no lowering changes.

3. Two DeclarationPrinter bugs (only reachable once 1+2 let the multilevel test — the first with class B extends A inside the exported decl text — get far enough):

   • The extends clause printed the class's own name instead of the base's (unused loop variable): class B extends M.B. The importer built a self-cycle in baseClasses and stack-overflowed in getVirtualTable's unguarded recursion (0xC00000FD, root-caused via ProcDump + WinDbg).
   • The synthetic base-class storage field (memory layout, not a source member: M.A: [.vtbl:Opaque, a:number];) leaked into the printed decl as a real field, shifting every subsequent field's offset in the importer — silent data corruption: the DLL's methods saw b=22 while the importer read c.b == 0 one slot past it.

Per the design doc's hard-won lesson, not touched: fullNameGlobalsMap scoping, the generic dynamicImport branch's name computation, decorator synthesis. Doc updated with the resolution (§10).

Test plan

• All six -shared class-extends tests pass (compile + JIT × basic/multilevel/diamond) and are enabled in CMakeLists.txt
• Full ctest suite green: 767/767 (761 prior + 6 newly enabled) — the previous attempts' regressions were only visible suite-wide, so this was the gating check

🤖 Generated with Claude Code