Stop returning unwanted __typename fields in cache results.

[benjamn]

This change was extracted from #5154, per @jbaxleyiii's approval.

If you read from the cache using a query that does not have explicit __typename fields, the cache should not return data containing the __typename field. Unfortunately, we have a bunch of tests that currently enforce the accidental presence of __typename, so this relatively simple change required updating a lot of test code.

[benjamn]

We still call transformDocument when writing to the cache, so any __typename fields in the result object will be stored in the cache, but when we're reading we need to use the original query as provided by the application.

[hwillson]

Love it @benjamn - thanks!

[benjamn]

With this change, we're no longer calling transformDocument or addTypenameToDocument anywhere in the InMemoryCache implementation!

[benjamn]

Closing in favor of #5320, which guarantees __typename will be included in cache results as long as addTypename is true (which the the default behavior for InMemoryCache). That's roughly the opposite of what this PR tried to do, but it makes more sense, all things considered.

After further discussion with @jbaxleyiii, we've come to the conclusion that hiding __typename fields would have needlessly disrupted readFragment => transform => writeFragment workflows, because writeFragment needs __typename information to work properly, so readFragment must return that information.

The final hack that I implemented in 7d1df90 (including __typename fields but making them non-enumerable) was not sufficient, because object spread syntax only picks up own enumerable properties, so patterns like this would still fail:

const data = cache.readFragment({ id, fragment });
cache.writeFragment({
  data: {
    ...data, // fails to copy __typename
    todos: [mResult.data.createTodo, ...data.todos],
  },
  id,
  fragment,
});