Ergonomic improvements for field policy merge and keyArgs functions.

[benjamn]

This PR introduces two minor improvements for merge and keyArgs functions in field policies.

First, if you need to write a custom keyArgs function (unusual), you can now access the variables of the current read/write operation through context.variables.

Second, you can now write

new InMemoryCache({
  typePolicies: {
    Book: {
      fields: {
        author: {
          merge: true,
        },
      },
    },
  },
})

as a shorthand for

new InMemoryCache({
  typePolicies: {
    Book: {
      fields: {
        author: {
          merge(existing, incoming, { mergeObjects }) {
            return mergeObjects(existing, incoming);
          },
        },
      },
    },
  },
})

to enable merging of author objects associated with a given Book.

You can also specify merge: false to do the opposite:

new InMemoryCache({
  typePolicies: {
    CourtCase: {
      fields: {
        verdict: {
          merge: false,
        },
      },
    },
  },
})

This ensures the verdict field of the CourtCase object always overwrites any existing verdict, without warning about clobbering data (see #6372). In other words, merge: false is a shorthand for

new InMemoryCache({
  typePolicies: {
    CourtCase: {
      fields: {
        verdict: {
          merge(_, incoming) {
            return incoming;
          },
        },
      },
    },
  },
})

[hwillson]

I love these enhancements @benjamn - great ideas!

[glasser]

This looks like what we talked about! Nice!

[glasser]

I can't usefully review this part of the test without a lot more learning.

[justinanastos]

This provides features I didn't even know I wanted; thank you @benjamn !

[benjamn]

These improvements are available now in @apollo/client@3.1.0 (just published to npm).

[JesseZomer]

First, if you need to write a custom [`keyArgs`](https://deploy-preview-6714--apollo-client-docs.netlify.app/docs/react/caching/cache-field-behavior/#specifying-key-arguments) function (unusual), you can now access the variables of the current read/write operation through `context.variables`.

@benjamn Do you think it's possible to also get access to these variables when writing your custom keyargs function? I have some types that don't have unique enough data (think weeks in a calendar). But together with the context from the query they do.

A week number is not unique enough (if you have multiple calendars) but it is in combination with the calendar id. And the only way to get the weeks is through a calendar query.