#2264: Set environment variables of all installed tools when running a tool

[maybeec]

This PR fixes #2264

Running a tool via ide «tool» «args» did not provide the environment variables of the other installed tools of the project - only the invoked tool and its declared dependencies got their setEnvironment applied. The environment was therefore computed by two disagreeing code paths (ideasy env iterated over all installed tools, the tool run did not). Symptom from the issue: ide npm run tauri:dev failed because CARGO_HOME/RUSTUP_HOME were missing although rust is installed via IDEasy.

Implemented changes:

• Extracted EnvironmentCommandlet.setEnvironmentVariablesInLocalTools into IdeContext.setEnvironmentOfInstalledTools(EnvironmentContext) (implemented in AbstractIdeContext) as single source of truth for the tool environment - used by ideasy env as well as by tool runs.
• ToolCommandlet now seeds every newly created tool ProcessContext with the environment variables of all installed tools (new private newToolProcess(...), used by runTool(...) and completeRequestProcessContext(...)). The invoked tool and its dependencies apply their own setEnvironment afterwards and therefore still take precedence.
• The extracted method gates on the existence of the tool installation directory instead of isInstalled(). isInstalled() spawns processes for some tools (e.g. Npm.computeInstalledVersion runs npm --version, npm-based commandlets run npm list -g «package»), which was tolerable for the rarely used env commandlet but would add seconds of latency to every ide «tool» call. Side effect: a leftover software/«tool» folder without version file now also contributes its variables - consistent with how SystemPath already treats those folders.
• cli/src/main/package/functions: a failing ide «cmd» no longer returns early. The shell environment is always refreshed via eval "$(ideasy env --bash)" and the original exit code is returned at the end, so a retry no longer starts from the same incomplete environment.
• Test: TomcatTest.testTomcatHasEnvironmentOfOtherInstalledTools - the tomcat test project now has rust pre-installed and catalina.sh/catalina.bat echo CARGO_HOME. Written first and verified to fail before the fix (CARGO_HOME=). The pre-existing testTomcat guards that precedence is unchanged (tomcat still gets the tomcat-specific JAVA_HOME of java 21_35, not the project version 8u402b06).

---

Testing instructions

Automated:

1. mvn -Dtest=TomcatTest test in the cli folder - testTomcatHasEnvironmentOfOtherInstalledTools asserts that CARGO_HOME of the installed rust points into software/rust/.cargo although tomcat only depends on java.
2. mvn -Dtest=EnvironmentCommandletTest,EnvironmentCommandletGlobalTest test in the cli folder - the output of ideasy env is unchanged.

Manual (the original scenario):

1. Use a project with rust and node installed via IDEasy.
2. In a fresh terminal, verify that the child process receives the rust variables:
   env -u CARGO_HOME -u RUSTUP_HOME ideasy node -e "console.log(process.env.CARGO_HOME, process.env.RUSTUP_HOME)"
   Both must point into «IDE_HOME»/software/rust (before this change they were undefined).
3. Run a failing command such as ide npm run does-not-exist and check that the environment of the shell is still refreshed afterwards (e.g. echo $CARGO_HOME is set) while echo $? right after the ide call still reports the non-zero exit code.

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

Note: this PR does not add a new tool commandlet, so the commandlet checklist does not apply.