fix: resolve TypeScript built-in type name collisions in CRD imports

[mateo-moon]

Summary

Fixes #3800

When a CRD's kind name matches a TypeScript built-in utility type (e.g., Record, Map, Set), the generated code creates a class that shadows the built-in type. This causes TypeScript compilation errors when the generated toJson_* functions use types like Record<string, any>.

Changes

Added a post-processing step in src/import/crd.ts that:

1. Maintains a list of TypeScript built-in utility types that may conflict
2. Detects when a CRD kind matches one of these types
3. Adds a type alias (e.g., type JsonRecord<K extends keyof any, T> = { [P in K]: T };) at the beginning of the generated file
4. Replaces usages of the built-in type with the alias (e.g., Record<string, any> → JsonRecord<string, any>)

Example

For Cloudflare's DNS Record CRD, the generated code now includes:

// Type alias to avoid collision with the Record class defined below
type JsonRecord<K extends keyof any, T> = { [P in K]: T };

export class Record extends ApiObject {
  // ...
}

export function toJson_RecordProps(obj: RecordProps | undefined): JsonRecord<string, any> | undefined {
  // ...
}

Test Plan

• Verified TypeScript compilation passes
• Manual testing with Cloudflare DNS Record CRD
• Consider adding unit tests for the fixBuiltinTypeConflicts function

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mateo-moon]

Rebased onto the current 2.x head. While running this patch in production we found three follow-up issues, and the fixes are now included here: the type alias is emitted only once for multi-version CRDs, runtime calls such as Object.entries/keys/values are redirected to a preserved _Object alias, and those runtime replacements are applied to every CRD generated into the same file. The full local test suite passes. This still addresses #3800, which remains open. @iliapolo could you approve the workflow run and review?