Provide Angular build context to external tool configuration files

# 🚀 Feature request

### Command (mark with an `x`)

- [X] build

### Description

Spin off from PurgeCSS discussion in #20015.

It would be nice for external tool configuration files (like Tailwind) to have some knowledge about the Angular build context in order to conditionalize their configurations. This could allow `ng build --configuration production` to change the config used by other tools and affect their builds as well. This allows other tools in a project to be more intelligent about the intent of a build and do what the user expects.

### Describe the solution you'd like

There are a couple possible implementations of this.

1. Set an environment variable like `NG_BUILD_CONFIGS="foo,bar,baz"`. Then config files could do something like:

```javascript
const enableOptimizations = process.env['NG_BUILD_CONFIGS'].split(',').includes('production');
```

This would decouple the Angular CLI from any specific tools and allow the individual tool configs to define the semantics for each configuration. Similarly, the semantics for each configuration are also defined directly in the tool's config file rather than `angular.json`. That seems weird to me, but arguably it's a benefit so :man_shrugging:. It also means that the config needs some knowledge of Angular, which isn't too bad considering its in the config, not the tool library, but this can still be undesirable.

2. Add an `env` option in `angular.json`. Each configuration in the `angular.json` file could include an `env` map that looks like:

```jsonc
{
"projects": {
"my-project": {
"architect": {
"build": {
"options": {
"env": {
"MY_BUILD_ENV": "development",
},
},
},
"configurations": {
"production": {
"env": {
"MY_BUILD_ENV": "production",
},
},
},
},
},
},
}
```

The Angular CLI would parse and set the relevant environment variables during a build. Then tool configs could look for the project-specific environment variables like so:

```javascript
const enableOptimizations = process.env['MY_BUILD_ENV'] === 'production';
```

This would still give users full control over the semantics of any given environment variable and they can choose its value on a per-configuration basis. The challenges here include merging multiple configuration environment variables which might conflict and that this environment would apply to all tools used by the Angular CLI. Users might also break something by setting a variable they probably shouldn't (such as `PATH` or other system variables) and breaking the CLI.

3. Just have users set the environment variable on the command line:

```shell
MY_BUILD_ENV="production" ng build --configuration production
```

Then use that variable in the tool config just like previously:

```javascript
const enableOptimizations = process.env['MY_BUILD_ENV'] === 'production';
```

This requires no effort on the Angular CLI side and users can do this today. The downside here is that it requires special knowledge of how to build a particular app. A new developer would reasonably expect `ng build --configuration production` to do everything it needs to, and then be surprised something didn't optimize because they didn't set `MY_BUILD_ENV="production"`. Projects could wrap such a command into an `npm run build:prod` which sets the variable, but not everyone will use it. This is also a cross platform issue, as I don't think there is a Unix and Windows compatible way of doing this (see [this question](https://superuser.com/questions/1405650/setting-environment-variables-for-windows-cmd-temporarily-to-run-a-program-in)), so supporting both environment for build is more hassle for the user.

There are likely other possible implementations that have their own trade offs. We'll need to discuss this more and come to a decision on how to move forward here.

首先检查 `ng build` 如何读取 `angular.json` 中的构建选项和配置，然后阅读 #20015 中相关的 PurgeCSS 讨论。在开始实现之前，需要从所提出的环境变量方案中作出决策；完成的条件是具备一致同意的设计、文档化的配置语义，以及对配置合并和平台行为的覆盖。

由索引模型根据 Issue 内容生成。