fix(gatsby): Multi-environment browserslist configs

[chrissantamaria]

Description

This PR fixes the logic in getBrowsersList to properly handle multi-environment Browserslist configs.

More info available in #29943, though the root issue is the current logic always choosing config.defaults - with a multi-environment config, this may return [] which (improperly) passes through the current logic check. This can have some pretty undesirable effects on parts of the build, including it currently breaking the hasES6ModuleSupport helper and causing a build failure (see the reproduction repo).

Fortunately, the fix is pretty simple: browserslist exposes a loadConfig function which has all of the necessary logic for picking the right config, including falling back to defaults for the majority of cases. I haven't found a case where this breaks existing behavior, though please double check me on this!

As an added bonus, loadConfig also respects the BROWSERSLIST_ENV and BROWSERSLIST_CONFIG environment variables which should make customizing build behavior a bit simpler.

Related Issues

Fixes #29943

[chrissantamaria]

@wardpeet @LekoArts sorry for the ping - just wanted to check on the status of this PR. I've confirmed this is still an issue on the latest Gatsby version (see updated reproduction repo) and that my PR still fixes the issue. I've rebased the PR with the latest master.

It's been nearly 2 years since the original issue was opened 🍰 so I'd really like to push this forward. Happy to make any necessary changes - thanks!

[LekoArts]

Really sorry for the long wait! LGTM 👍

[chrissantamaria]

Thanks for merging! 🎉

As a heads up, this PR should fix the underlying issue behind #29954 if you want to revert back to a Webpack target of browserslist - looks like this might result in more modern runtime code generation rather than always falling back to a target of es5. Tried it out locally and seems to (slightly) reduce overall bundle size, though I haven't benchmarked any performance improvements.