Adds {field}.hooks.validate.[create|update|delete] hooks

[dcousens]

Similar to #9056

This pull request needed to adopt a slightly different approach, since we can't reasonably change the types of field hooks when field types are part of our public API, and they are not statically determined by nature as the field types themselves return functions, not an object like list.

This is only a slight inconvenience though, since we can throw a runtime error to prevent incompatibilities at the point of creating the GraphQL resolvers (parseFieldHooks). I do want to flatten this in the future, but, for optimistic usecases you could start using .validation.* field hooks now. This won't be compatible with many of the native field types, but that compatibility can come later.

Additionally, as part of this pull request (and part of the validateInput hooks), the text now accepts a default value type of null. This was mentioned as a pain point in #7158 (reply in thread), but has remained unresolved for some time.

If db.isNullable: false, and you pass defaultValue: null, you will end up with a Prisma error if your text input is undefined (this behavior is typical of other fields). If db.isNullable: true, then defaultValue: null will be exactly that.

[dcousens]

We cannot extend the type without it being a breaking change

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 26d3772:

Sandbox	Source
@keystone-6/sandbox	Configuration

[dcousens]

This is a type error, and I think we should remove this in the future

[dcousens]

I think the distinctions between our nulls is poorly defined. We have too many nulls.

• GraphQL is String | String!, throws type errors
• Hooks for validation when isRequired: true, throws validation errors
• Prisma String? | String, throws prisma errors

Arguably we can unify some parts of this, or restructure it for progressive enhancement with less "conflicting" configuration.
At the least, validation: { isRequired: true } is unhelpful when you can use GraphQL to ensure the input is required.
We should leverage that instead.

Leaves some questions around context.db, but, that has many questions already... anyway.
This pull request doesn't change any of that, but, it is becoming increasingly obvious to me that we should do something different for that.

[dcousens]

Unlike other fields, the ambiguity of ?: representing '' or null is why this needs to exist.
We should allow null as a defaultValue typically, and maybe check it at build time too.