Move apollo-engine-reporting signatures into apollo-graphql.

[abernix]

Many of these signature calculation functions are now utilized in tools or helpers which are not directly related to apollo-server functionality, including various aspects of the apollo CLI which live within the apollo-tooling repository.

Currently, because of apollo's dependency on apollo-engine-reporting for
this signature, this requires bringing in the entire dependency tree since apollo-engine-reporting depends on apollo-server-core.

By moving this into this new apollo-graphql utility library, we're able to trim that rather hefty dependency tree and drastically reduce the download for running, say, npx apollo.

Furthermore, this PR makes the additional change of switching to the modular lodash.sortby package instead of using the whole of lodash. (The only place we use lodash in the entire apollo-server
repository is to utilize the sortBy function for this signature generation.)

Looking at the bundle stats, it appears that lodash represents 7.1% of the apollo-server package. We're a server, so bundle size is generally less of a concern, but it's still not to be ignored and it's something we want to work on, particularly as we move into worker environments. But, back to the immediate concern about the apollo CLI, since this package will be utilized by the apollo CLI, we'll be shaving additional precious download time off the invocation of npx apollo if we can get this down.

We'll still depend on @types/lodash for just the ListIteratee type (since the modular packages don't provide the lodash/common types) and we should be able to trim 55.4kB minified (19.1kB minified+gzip'd) off the apollo-server build.

cc @trevor-scheer @jbaxleyiii @martijnwalraven

[glasser]

Moving this out of the reporting package sounds like a great idea.

A few thoughts:

• This is a backwards-incompatible change to apollo-engine-reporting due to the lack of exports. I think you understand this (the major version bump, etc) but I'd be curious to know if we had any knowledge of people actually using the exports to pass a custom calculateSignature in.
• Looks like the documentation of calculateSignature in apollo-server.md could at least a tiny update to reference the new package.
• What if the new package's name was more specific? apollo-graphql is pretty vague (it's basically our company's name!) How about something more like apollo-graphql-query-format or apollo-graphql-query-normalize? Note that my personal instinct is to try to eventually move our company towards a world where "signature" is literally just a well-defined lossless whitespace and sort order normalization.

[abernix]

Concretely, once published and consumed this solves an undesired dependency on apollo-server-core by the apollo CLI. As it stands right now though, those signature algorithms also need to be used by both the apollo-tooling repository (which houses the apollo CLI) and (this) apollo-server repository (which houses apollo-engine-reporting).

We can explore moving formatting functions into another package if it makes sense but there are more concrete plans (which, admittedly, are yet to be fully publicized and finalized) for this package aside from it being a home for signature algorithms, which is certainly not its sole purpose.