docs: production build optimization

[sarahxsanders]

First guide in the new GraphQL production guide series, focusing specifically on build optimization for production deployments. Content covers:

• Environment variable configuration for GraphQL.js optimization
• Dead code elimination and tree shaking setup
• Browser compatibility handling
• Code splitting strategies
• Build tool configurations for Webpack, Rollup, and esbuild
• Bundle analysis and verification steps

I'd love feedback and a review, but please do not merge until the entire production guide series is ready to ship. The focused guides will replace the production monolith that exists today

[sarahxsanders]

this guide and the following others are ready for review whenever:
#4508
#4509
#4490
#4516

[yaacovCR]

• A general question/comment: this PR and the related PRs should hopefully take over for the current "going to production" section, right?

• in terms of this one specifically, I think we need to distinguish between what graphql-js itself does in dev vs production mode and the capabilities that graphql-js provides to libraries/services/tooling/clients using graphql-js, some of which might be useful only in development.

In particular, the only thing that graphql-js currently does internally in development mode both in v16/v17 (and I believe v15 and perhaps earlier?) is enable some extra checks within every internal instanceOf() call that powers all graphql-js predicates and causes a minor increase in bundle size and a performance hit.

A good example of the second category of capabilities that graphql-js provides is the 'assumeValidoption that when used will cause the automatic call tovalidateSchemawithinvalidate()andexecute()to short-circuit, i.e. returning without errors. And something similar withinassumeValidSDLwithinbuildSchema/buildASTSchema/extendSchema`.

That's in terms of options, but in terms of functions, any client code that directly calls validateSchema() on a trusted schema or even validate() on a trusted document can be skipped in production.

Note that in v17, we are changing the internal instanceOf to no longer be directed by the NODE_ENV, but rather by the production vs development condition (building on our new support of conditional exports) and with production behavior now enabled b default. See: #4551