Improve test-projects and test-infrastructure to use dynamic download via wiremock

[hohwille]

Currently for our integrative tests of commandlets we added a hack that will override the regular software download with a test-implementation that copies a folder recursively instead:

IDEasy/cli/src/test/java/com/devonfw/tools/ide/repo/ToolRepositoryMock.java

Line 45 in 4673d68

public Path download(String tool, String edition, VersionIdentifier version) {

Instead, we could actually test the real code by just adding a writemock server to AbstractIdeContextTest that serves the directory content and dynamically delivers it as TGZ file (or whatever the URL suffix may be, we can also support ZIP, but we do not plan to support MSI, DMG, PKG).
Then the dummy urls files need to point to the wiremock server and should be in the following format:

${testbaseurl}/download/«tool»/«edition»/«version»/«filename»

Here ${testbaseurl} will be replaced with the base-URL to the wiremock server such as http://localhost:8765 while the port-number is randomly generated (see #223).
The values for «tool», «edition» and «version» should be obvious and even though they are kind of redundant since the urls file is already in a folder structure containing exactly this information, I would still propose to add this explicitly.
I suggest the download folder to avoid clashing conflicts with other aspects that may be needed to be mocked with wiremock in the same test.
The «filename» should typically be «tool»-«version».tgz but as needed by the test, this could also be in the format used by the real download (e.g. zip extension, different file-name-structure).

The wiremock server should react to any GET request inside the download folder.
It should then be able to extract «tool», «edition» and «version» as well as the file extension from the URL.
Only tar.gz with its synonym tgz and zip with its synonym jar will be supported as extensions (not msi, dmg, pkg, etc.).

The wiremock rule for this will then find the folder with the mocked software as done by the current implementation and create an archive package on the fly via GZip, Tar, and Zip streams just like we do on extract method but vice-versa (compress instead of extract).