Closes #133.

renameShadowedNamesInExpr mishandled local recursive groups in two ways. The fold over group members consed each processed member onto an accumulator and never reversed the result, so every local RecursiveGroup came out with its members in reverse order. Member order is the initialization order computed by the laziness transform, so an eager member (for example the name = Lazy_name(0) forcing binding of a runtime-lazy group) could run before the member it reads was assigned, and the generated Lua crashed with "attempt to call a nil value". The second defect: each member's RHS was renamed in the scope accumulated over the previous members only, while recursive-group scoping makes every member visible in every member's RHS, itself included (see Note [Sequential scoping of Let bindings]). A group member that shadowed an outer binder had its self- and forward references quietly rebound to that outer binder, severing the recursion.

The fix processes each group in two passes: first it brings all the members into scope (avoiding names bound anywhere in the group), then it renames every RHS in the complete group scope. Member order is preserved.

Tests, written red first:

• Three unit tests in the "renames shadowed names" block cover order preservation, self-references and forward references. All three failed on the old code.
• A new golden module Golden.RecGroupOrder pins the runtime consequence. Its lazy self-reference (a reference under a lambda passed as a function argument, which the laziness analysis treats as potentially forced at initialization) compiles to a Lazy_record/record pair whose order is load-bearing. With the fix reverted, the generated Lua crashes with attempt to call local 'Lazy_record' (a nil value); with the fix it prints ok!.

The Golden.RecursiveBindings churn is the reversal disappearing: member order now matches what the laziness transform emits. Both members there are lambdas, so the old order happened to be harmless.