Fix object-literal generator method typing; extend generator .next() test coverage

[ASDAlexander77]

Summary

• Fixes object-literal generator methods ({ *gen() {...} }, { gen: function*(){} }) typing a call's return as the bare yield-tuple [value, done] instead of the generator wrapper object, which broke .next()/for...of. Class generator methods already worked; root cause was processObjectFunctionLikeProto computing the field type via mlirGenFunctionPrototype directly instead of going through the generator-aware dispatch class methods use. Fix extracts a buildGeneratorWrapperDeclaration helper (behavior-preserving refactor of mlirGenFunctionGenerator) and routes object-literal generator methods through it for prototype typing too.
• Adds 00generator7.ts: object-literal + class generator methods, manual .next() on a class generator method, independent-instance isolation.
• Adds 00generator_manual_next2.ts: interleaved independent generator instances, single-drain-via-helper-function, generator body closing over/mutated by outer state between resumptions, post-completion .next() calls.
• Registers all 4 new files as both compile and JIT ctest entries.

Known follow-up (not fixed here, documented in-repo)

Passing a generator as a function parameter and calling .next() inside the callee mutates a private copy — the caller's generator does not advance afterward. Generator objects have value semantics and are copied across the parameter ABI boundary, unlike same-function const locals (which reuse one alloca via a materialization cache). A real fix needs pass-by-reference semantics for generator/mutable-object parameters in mlirGenFunctionParams — broader in scope, deliberately out of scope for this PR. See the comment above drainTwo in 00generator_manual_next2.ts.

Test plan

• ctest -R generator -j4 — 18/18 passed
• Full suite: ctest -R ^test-jit- -j8 — 350/350 passed
• Full suite: ctest -R ^test-compile- -j8 — 354/354 passed