Migration generator uses new type name for old version when Union type is renamed

[CharlonTank]

Bug Description

When a Union type is renamed between Evergreen versions (e.g. MoralType in V51 → CompanyType in V52), the migration generator produces a function with an incorrect type signature. It uses the new type name for the old version:

migrate_LegalEntity_CompanyType : Evergreen.V51.LegalEntity.CompanyType -> Evergreen.V52.LegalEntity.CompanyType

But CompanyType doesn't exist in V51 — it was called MoralType. The correct signature should be:

migrate_LegalEntity_CompanyType : Evergreen.V51.LegalEntity.MoralType -> Evergreen.V52.LegalEntity.CompanyType

This causes the generated migration file to fail to compile.

Root Cause

In extra/Lamdera/Evergreen/MigrationGenerator.hs:

1. coreTypeMigration (line ~175) calls migrateUnionDefinition with typeName (the new name) instead of typeNameOld (the old name extracted from the pattern match)
2. migrateUnionDefinition passes only the new type name through to migrateUnionDefinition_
3. migrateUnionDefinition_ (line ~279) uses the same typeName for both the old and new type in the generated type signature

The Alias case (migrateAliasDefinition) already handles this correctly by accepting and using both typeNameOld and typeNameNew — the Union case was not doing the same.

Steps to Reproduce

1. Have a Union type in version N (e.g. type MoralType = SCI | SAS | SARL)
2. Rename it in version N+1 (e.g. type CompanyType = SCI | SAS | SARL)
3. Run lamdera check to generate the migration file
4. The generated migration file will have a type error because it references the non-existent new type name in the old version's module

Fix

PR #81 threads typeNameOld through migrateUnionDefinition → migrateUnionDefinition_, following the same pattern as migrateAliasDefinition.