Make doInstall even more generic

[hohwille]

We have already put a lot of energy, thoughts and magic into doInstall.
However, our commandelts still contain a lot of boiler-plate code for setup that could be eliminated:

• With our new version stuff (List available versions for a tool #826, Generic way to output tool version  #847, Use default tool version from available-versions #878, etc.) we can now always check if .devon.software.version is present and matches the version to be installed after it is resolved (Use default tool version from available-versions #878 and Ability to configure version prefix #893). Therefore we can determine if the configured version is already installed easy and fast.
• Therefore we can always check this and pass silent flag to doInstall handling all the expected logic behind it:
  When the version already matches (see point above) nothing should be done or logged if silent is active.
  However, if it does not match, we can update automatically - even if silent mode. This would bring a nice improvement so tools are all automatically updated (not only on non-silent setup) if version variable has changed.
  If not silent, we can always do the version check output (see doGetSoftwareVersion) at the end of doInstall. This shall honor TOOL_VERSION_COMMAND variable as well as if target_path ($2) is not pointing inside software folder so that exotic commandlets do not trigger this what may be undesired (e.g. if the download a global installer via doInstall like in docker or currently in aws).
• Further, we can improve doInstall to automatically detect if doExtract created nothing but a single folder inside the target_path (not named bin or Contents). If that is the case, then we could get rid of this extra folder. E.g. currently Eclipse on MacOS creates folder structure software/eclipse/Eclipse.app/Contents and after extracting *.dmg the eclipse folder contains nothing else but Eclipse.app.
• Then we could improve MacOS app workaround (see Generalize MacOS app workaround #683) in doInstall. If the target_path contains a MacOS app we could find the binary in a more generic way. Currently we search for Contents/Home/bin what matches for Java on MacOS. However, we could search all sub-folders (maybe except Resources or _* for _CodeSignature) if they contain a bin subfolder. In that case we should symlink that like currently done with Home folder for Java on MacOS. If no such folder exists, we can search for a folder directly containing an executable file (e.g. software/eclipse/Eclipse.app/Contents/MacOS/eclipse) and then symlink that folder. Then we would have software/eclipse/ being a symlink to software/macos/eclipse/Contents/MacOS and therefore contain nothing but eclipse binary and .devon.software.version. Thus it would be added directly to the PATH variable (no bin subfolder) and calling eclipse would directly work. To make a long story short. This way we could get rid of MacOS specific workarounds in eclipse commandlet. If we once consider "Java < 11" as obsolete legacy (maybe not this year) we can reduce doSetup to just an invocation of doInstall for most commandlets what would be an awesome simplification (of commandlets and a complication of the magic in doInstall).

[hohwille]

IMHO this issue is blocked by:

• Use default tool version from available-versions #878
• available-versions for java incomplete #931
• available-versions for java invalid #933