Add warnings for Field Access Control limitations with context.db

[dcousens]

This pull request adds a warning to the field access control documentation to clarify that field access control rules do not apply when using context.db.* for database operations.

Keystone has a number of access control capabilities, including field-level access control for read, create, and update field operations. The behavior of context.db.* not adhering to {field}.access.read is likely not apparent to many developers, especially when many developers often prefer context.db.* for the refined Typescript support.

Field access control has been designed to co-operate with GraphQL resolvers, ensuring that any data returned by your GraphQL API respects the field access control rules for a set of particular output types. We refer to this in the documentation as

field-level rules for... Read - [are] applied when the field is selected through any GraphQL operation

Since context.db.* operations don't pass through the GraphQL layer, and interact directly with Prisma, applying read field-level access controls isn't straight forward. You especially need to consider that many fields don't have reasonable behavior without passing through GraphQL output resolvers first, such as virtual fields.

---

That said, developers are incentivized to use context.db for the superior Typescript integration at this stage of Keystone 6's development, therefore we need to capture these limitations more readily in the documentation; and we should potentially review this behaviour in upcoming major versions.

This pull request adds some warnings that explicitly state that access.read field access control rules are not applied to context.db operations. This should help prevent confusion until we bridge the gap between context.query and Typescript.

[emmatown]

Might be worth noting in the docs that if you return what you get from context.db in a GraphQL resolver, read field access control will apply?