Move utility functions out of apollo-env, leaving polyfills.

[abernix]

The apollo-env package has a number of purposes today, including providing polyfills for runtimes that lack more modern features, providing utility functions (like, createHash that works on non-Node.js environments) and offering a common predicate function like isNotNullOrUndefined - a function that we use in many places in the Apollo ecosystem.

The polyfills have proven useful on environments that necessitate them, offering newer ECMAScript functionality in runtimes that don't yet have them, but they're automatically loaded from the main module entry point of this library, rather than being selectively enabled. For example, it's not uncommon to see import 'apollo-env'; in other packages that rely on the functionality.

It's this automatic eager loading of polyfills that proves to be problematic when the utilities and predicate functions of this library come into play though. Imagine a package that merely needs to use a version of createHash that simply falls back gracefully to a JavaScript version, or a function that wants to utilize the useful mapValues function, but in a circumstance where we - or our users - don't want to be subjected to the nature of polyfills affecting the runtime (see related issues like apollographql/apollo-server#2634).

Another circumstance that arises, which was the most motivating factor for me in this case, is that the apollo-env package has consistently proven difficult for bundlers to traverse, possibly because of the polyfills, possibly because of the side-effects, possibly because of both! However, in my times trying to bundle our Apollo packages over the years, I've encountered problems with Webpack, Snowpack, Rollup.js and now esbuild.

Most of these functions are small enough and simple enough that the duplication cost isn't all that high. For example, in my changes in this commit, rather than paying the cost of relying on an other package for what is basically a one-line function, I've just copied and pasted isNotNullOrUndefined into a couple places where it is needed. Furthermore, since most of the utilities that were being leveraged from apollo-env were being leveraged by the apollo-graphql package, I've just moved those into that package instead.

Packages that just need the utilities can rely on apollo-graphql. Any runtimes that still necessitate polyfills like Array.prototype.flat or Array.prototype.flatMap can still import "apollo-env"; directly for those side-effects to be applied to their runtime We can just use core-js-pure to gain the same, well-tested functionality without the overhead of polyfills and the impact those have on consumers/bundlers. Again though, most of our packages are depending on both already so creating the more distinct separation seems not-all-that-unreasonable. Furthermore, while apollo-env does also provide some fetch polyfills which we need to keep, once Node.js 12 becomes the minimum version we support, I don't think we even need non-fetch polyfills anymore at all.

[abernix]

Suggested change

	// TODO(Node.js 10): When we deprecate Node.js 10, remove this and switch
	// to using `Array.prototype.flat`.
	// TODO(Node.js 10): When we deprecate Node.js 10, remove this and switch
	// to using `Array.prototype.flat`. When doing this, deleting the hand-rolled
	// types in `./packages/apollo-gateway/src/types/` that go with it.