DX Split config for node vs browser environment

[CallMeLaNN]

I've been writing my DX about env var and Payload config here #1654 (comment) It is a small thing but the env context cause some confusions I've seen in some issues.

In a bigger picture config env and imported collections supposed to be easier to deal with env.

A: If we were to let config isomorphic/browser friendly like the current config, consider:

1. Limit the API not to let developer leak node related packages to browser env until we can make it clear about it.
   E.g. exposing webpack config seems like to give ability to fully customize it but we can't even add webpack plugins in payload.config.ts because those are require different env. So if it is just for webpack alias, just provide a way to make alias instead of all webpack config but we can simplify further, see no 2.
2. We can avoid to create empty mock file when importing a node library from our collections. E.g. we can supply an array of paths so that Payload will automatically mock and webpack alias it.
3. Have to look for possibility to show meaningful error instead of long error like this
4. Doc need to be clear about the config and all imported collections can't have node specific environment.
   Adding a comments in generated payload.config.ts from create-payload-app could be helpful but consider an alternative below.

B: Consider to split the config based on env like GatsbyJS is using gatsby-browser.tsx and gatsby-node.ts files independently. We can make one of it or another file like gatsby-config.ts for the common config.

1. A lot less confusion and mistake from developer since the API for each env is different. E.g. collection metadata is common, hooks is node, etc.
2. We can configure TypeScript not to add node global in browser env.
3. All of the above is clear and we can expose bundler API on node env.