support for tool dependencies #1178

As a devonfw-ide user, I want to have tools being setup with their correct dependencies so that it just works and I do not have to worry.

As illustrated by #1082 or #1170 it currently does not work well:
E.g. several tools have java as dependency:

• mvn
• eclipse
• intellij
• jenkins
• sonar
• ...

However, they may all require different versions of java ending up in an inconsistent situation that devonfw-ide currently cannot resolve. As a solution I see the following ideas:

• in ide-urls in each tool/edition version folder we will introduce a new (optional) dependencies file.
• this file will contain a list of 1-n tools with their required version or version range (similar to a dependency in maven, gradle, or npm).
• we can still discuss if that should be in JSON format (and then being named dependencies.json) or just a plain file with one dependency per line (TBD)
• if no such file is present, there are no dependencies required. Otherwise these dependencies have to be setup as well to launch the tool.
• in order to avoid conflicts between different versions of the same tool, we make the shared software repository the new default.
• the default java version for the build (e.g. for maven or gradle) will still be found in software/java but as a symlink to the configured JAVA_VERSION.
• However tools like eclipse/intellij/jenkins/sonar/... can require their own Java version via the dependencies file. If the default Java (JAVA_VERSION) does not match, then an additional java version is found or installed in the shared software repository and used instead by setting JAVA_HOME to it and adding it to the beginning of the PATH but only locally in the commandlet before launching the java based tool.
• we will analyze if we can find ways to automatically determine dependencies for specific tool versions. Where not possible, we will simply put the latest default into the according UrlUpdater class for that tool/edition and have to change it whenever a new version comes out that has different dependencies. If we notice too late (what might be the regular case), we have to change existing dependency version file(s) manually and also change the UrlUpdater then for future versions.
• all existing dependencies will need to be added via manual crafting what can be quite some effort.