Fix env vars not injected on WSL / remote targets (GoLand)

[sedovserge]

Problem

Fixes #258. On WSL (and other remote targets) EnvFile variables never reach the Go process.

Root cause

For a local run GoLand builds a GeneralCommandLine and calls the legacy
GoRunConfigurationExtension.patchCommandLine(..., GeneralCommandLine, ...) hook that EnvFile
overrides. For a target run (WSL, SSH remote) GoLand goes through the Targets API and builds a
TargetedCommandLineBuilder instead — the legacy hook is never invoked, so EnvFile injects nothing.

Verified on GoLand 2025.2.6.1: with logging in all three GoRunConfigurationExtension hooks, a WSL run
fires only patchExecutor and the target patchCommandLine(TargetedCommandLineBuilder, ...); the legacy
patchCommandLine(GeneralCommandLine, ...) does not fire.

Fix

Override the executor-level patchExecutor hook (which fires for both local and target runs) and inject the
resolved variables via GoExecutor#withUserDefinedEnvironment — the same channel the native run-config
Environment field uses, which is known to reach the target.

To avoid leaking host-only variables (PATH, ProgramFiles, windir, ...) into the target environment
(e.g. Linux under WSL, where a Windows PATH would be harmful), only the delta over the parent/host
environment is injected. Injection is limited to CommandLineType.RUN.

The local path is left untouched: the legacy patchCommandLine(GeneralCommandLine) still runs and, on local
runs, overwrites the command-line environment as before — so local behaviour is unchanged.

Scope

This addresses the GoLand module only. #258 also reports the same class of problem for PyCharm over SSH;
that would need an analogous change in the respective product module and is out of scope here.

Testing

• GoLand 2025.2.6.1, WSL2 (Ubuntu), real Go microservice with a .env: variables now reach the process and
  the service starts; injected set contains the service variables and none of the Windows host variables.
• Local (non-WSL) run: no regression, variables load as before.