feat: allow to set web/webworker and node environments

[alexander-akait]

What kind of change does this PR introduce?

Feature. Why we need to expose them:

• https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L473, webpack-dev-server uses overlay, so to automatically understand whether it should be used or not we should check is it web target (but not webworker)
• css-loader has https://github.com/webpack-contrib/css-loader?tab=readme-ov-file#exportonlylocals, we can automatically enable it when enviroment is node

Why we can't use just target? Because developer can have target: "browserslist" and to undestan the right enviroment we need to do load and resolve it (webpack already does it, so no need to duplicate it)

Also there is a fix for bigIntLiteral, because we use the optimistic strategy when nothing avaliable for ECMA features

Did you add tests for your changes?

Yes

Does this PR introduce a breaking change?

NO

What needs to be documented once your changes are merged?

New options

/cc @vankop

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[alexander-akait]

We use the same for const/forOf/etc, so let's use the same here when no targets avaliable

[vankop]

need to think about this carefully.. idea of environment option is to understand does environment support some features ( basically js features now ). Maybe store additional target information? so we wont need to resolve browserlist twice

[vankop]

something like class Target. Instance of which will be assignment to compiler and then use something like compiler.target.isNode()

[alexander-akait]

@vankop Yeah, I thought about it, but we have target: false (i.e. you can setup your own env), so when you have target: false, you need to ability to setup all envs, so you can flexy setup which features/things your env supports

[vankop]

@alexander-akait target: false is a strange edge case.. we can warn on something like this.. but better stick to webpack design and by design target option should be used in this cases.

[vankop]

wdyt about this design @alexander-akait #18378 ?

[alexander-akait]

@vankop Yeah, looks good, I put a comment about loader context there