Preserve CustomBeforeMicrosoftCommonProps with dotnet run/test -e

### Describe the bug

`dotnet run -e NAME=VALUE` and `dotnet test -e NAME=VALUE` use a generated temporary `.props` file to pass environment variables to opted-in projects as `@(RuntimeEnvironmentVariable)` items.

The generated file is injected by setting the global `CustomBeforeMicrosoftCommonProps` property. If the user already supplied that MSBuild extension point, the CLI replaces the value, silently dropping the user's import.

This currently affects `dotnet run`; `dotnet test` uses the same shared helper in #55325 and would have the same behavior.

### Steps to reproduce

1. Create an opted-in project that declares:

```xml

```

2. Create `custom.props` with observable build behavior, for example a target that writes a marker or logs a unique message.
3. Run either command:

```console
dotnet run -e FOO=BAR -p:CustomBeforeMicrosoftCommonProps=custom.props
dotnet test -e FOO=BAR -p:CustomBeforeMicrosoftCommonProps=custom.props
```

The command succeeds, but the behavior from `custom.props` does not occur.

### Expected behavior

The generated environment-variable props and the user's existing `CustomBeforeMicrosoftCommonProps` import are both applied.

### Actual behavior

`EnvironmentVariablesToMSBuild.AddPropsFileToArgs` adds `CustomBeforeMicrosoftCommonProps` through `MSBuildArgs.CloneWithAdditionalProperties`. The additional property replaces the existing value, so the user's extension-point import is silently ignored.

### Is this a regression?

The issue exists in the current `dotnet run -e` implementation introduced by #52664. `dotnet test -e` reuses the same mechanism in #55325.

### Are there any workarounds?

A short-term SDK fix could have the generated temporary props file import the original `CustomBeforeMicrosoftCommonProps` value before declaring `@(RuntimeEnvironmentVariable)`, then point the global property at that generated wrapper.

Users can otherwise move their import to another project hook, but that may change evaluation ordering and is not always equivalent.

### dotnet --info output

N/A

### IDE version

N/A

### Other details

Ideally, environment-variable items could be supplied to out-of-process MSBuild without creating a temporary props file or consuming a single-value MSBuild extension point. MSBuild command-line properties cannot currently define items with metadata, so avoiding the file may require a new .NET SDK or MSBuild feature. This issue should track investigation of that design as well as the immediate import-composition fix.

Related review: https://github.com/dotnet/sdk/pull/55325#discussion_r3601598872