feat!: various type improvements

[AlessioGr]

Description

• Globals are no longer typed as TypeWithID or GlobalTypeWithID, as globals do not have IDs. Now they are just Record<string, unknown>
• Extract common types into utilities. These are useful for properly typing our seed data, e.g. here (https://github.com/payloadcms/payload/pull/6385/files#diff-275a5bc9d2d469e19efe811b4431787d02a79db73cde145f7f81f5027c0f6c9fL4). It also makes it easier to read and clearer what this type actually does. Additionally, we can properly search for usages of these now:
  • GeneratedTypes['collections'][TSlug] to DataFromCollectionSlug<TSlug>
  • MarkOptional<GeneratedTypes['collections'][TSlug],'createdAt' | 'id' | 'sizes' | 'updatedAt'> to RequiredDataFromCollectionSlug<TSlug>
• Make all operations uniformly accept Slugs as generic. Previously, some accepted slugs, some accepted data. It was chaos
• Rename T generics into more descriptive ones (TSlug or TData)
• Remove unused generic from BasePayload as we always use GeneratedTypes anyways
• Add optional TSlug generic to CollectionConfig. Currently it's used to properly type the AfterOperationHook result. In a later PR, I want to trickle that down to all the other hooks which are currently mostly untyped!
• relationTo is now properly typed to the collection slugs (from generated types)!
• Lexical: Arguments for relationship, link and upload features (e.g. enabledCollections) are now strongly typed to the collection slugs (from generated types)
• Keys from GeneratedTypes are now only strings instead of number | string | symbol with the help of a new StringKeyOf utility type. This makes keyof operations on them more reliable

BREAKING:

• Type narrowing for relationTo props on filterOptions, relationship fields and upload fields
• Type narrowing for arguments of lexical relationship, link and upload features

• I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

• Chore (non-breaking change which does not add functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Change to the templates directory (does not affect core functionality)
• Change to the examples directory (does not affect core functionality)
• This change requires a documentation update

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• Existing test suite passes locally with my changes
• I have made corresponding changes to the documentation