Improve plugin support

[hohwille]

As a IDEasy user, I want to be able to push out a new required plugin to my teams with a simple push to my settings git repo so that everybody in my team can automatically get this new plugin installed.

Currently we already have support for automated plugin installation in all our major IDEs.
However there are some problems:

• When a new plugin has later been added to my settings as active neither ide update nor pulling the settings and restarting the IDE will install the plugin. As a workaround, I have to uninstall the IDE and install it again (maybe after manually deleting the according plugins folder). This should happen automatically.
• When an automated plugin installation failed, it will not be retried again. E.g. if there is a temporary network issue or an unavailability of the plugin provider download site, it will not be repeated. We should either implement a logic that can detect if a specific plugin is installed per IDE individually or we could write a marker file after successful installation of the plugin based on the plugin name (not ID since for eclipse that is a comma separate list that can get very long and maybe cause errors in Windows filesystem) and then implement a generic mechanism in PluginBasedCommandlet. Then when we launch the IDE, we can (re)install missing plugins automatically. Ideally we also provide an option to disable this feature.
• We should improve the error handling for plugin installations. At least for Eclipse, I gets pages of crazy HEX output logged to the console. If that is retried for every launch this can be considered as annoying spam. E.g. we could just log the last max N lines of std-error and then refer to a logfile for further details. I already changed the loglevel of std-out to debug in PR #593: #651: #564: #439: fixed bugs, refactored tool dependencies #652
• When the user manually removes or uninstalls a plugin, we need to still define what should happen. At least a warning should be logged. We should clarify if we instead want to reinstall it anyway - the problem is that then the user cannot easily get rid of a plugin and may be annoyed if he uninstalled a plugin that he does not like if it comes back on IDE restart. A possibility for the user is to override the plugin by copying the plugin properties file into ~/.ide/plugins/«ide»/«plugin-name».properties and set plugin_active=false.

Solution design and acceptance criteria:

• for every plugin we create a marker file after successful installation in $IDE_HOME/.ide/plugin.«ide».«plugin-name». Here «ide» is the name of the IDE like intellij or eclipse and «plugin-name» is the name of the properties file for the plugin excluding the extension.
• when we setup an IDE (e.g. ide install intellij or ide update) even if it is already installed in the correct version end edition, then we still check all active plugins. If the above marker file is already present, nothing has to be done for the plugin, but otherwise if will be installed.
• we IMHO need to track the edition of the IDE. The easiest way would be to write the edition to the file $IDE_HOME/plugins/«ide»/.edition. In case we setup and IDE, we check that edition file exists. If yes, we read the edition and if the configured edition mismatches, then we need to delete the folder $IDE_HOME/plugins/«ide» what then will trigger a reinstallation of all plugins.

As a result, if the user manually uninstalls a plugin, it will not be reinstalled automatically (unless the marker file also gets deleted).
This way we do not need to implement IDE specific detections to figure out if a plugin is already installed or not and also we give control and freedom to the user. If he really wants to manually uninstall an active plugin, then he should be able to do so but also take responsibility.
Also with the above design a plugin that failed to be installed, will be retried on the next setup as a logic consequence.
If this may be annoying for projects that have configured plugins that are somehow broken, we can create a follow up story.
However, projects should disable broken plugins. Anyhow, we could consider an option --ignore-plugin-errors that will write the marker files even in case of an error.