Introduce new cache.batch(options) method for InMemoryCache.

[benjamn]

As new methods have been added to ApolloCache and InMemoryCache, we have found it convenient in many cases (e.g. cache.evict and cache.modify) to use a method signature that accepts named options, rather than positional parameters. Named options are easier to extend in the future, and less cumbersome when some of the options might be omitted.

This awkwardness of positional parameters affects the two existing transaction-related methods of InMemoryCache:

cache.performTransaction(cache => {...}, id?);
cache.recordOptimisticTransaction(cache => {...}, id);

Instead of adding new functionality to these methods by introducing new positional parameters, I would very much prefer to switch to named options, but I was previously concerned that introducing a new transaction method for the ApolloCache superclass would be a breaking change for anyone not using InMemoryCache.

As this PR demonstrates, it is possible to introduce an ApolloCache method called batch with a default implementation that just calls this.performTransaction, so any custom cache implementation (not based on InMemoryCache) immediately inherits a usable version of the batch method. The subclass may choose to override batch to take advantage of its named options, but that's not mandatory. Either way, ApolloClient (specifically, QueryManager#markMutationResult) can safely start calling cache.batch instead of calling cache.performTransaction as it does now.

Of course, InMemoryCache overrides batch, and relocates most of the code that used to live in performTransaction into the new batch method. It's a much more powerful and ergonomic API, already allowing new functionality like the onDirty callback, and an options.transaction function whose first parameter has the subclass type (e.g. InMemoryCache) rather than the ApolloCache superclass type.

This PR is a stepping stone to implementing the following item from the Apollo Client v3.4 ROADMAP.md section:

• A new API for reobserving/refetching queries after a mutation, eliminating the need for updateQueries, refetchQueries, and awaitRefetchQueries in a lot of cases.

I will finish implementing those features in subsequent PRs, but you might already be able to guess how onDirty will help.

[hwillson]

This looks great @benjamn!

Side note - I think taking a long look at our continued support of the ApolloCache abstraction is something we should add to our 4.0 planning.