Add 'update' functionality to the dita install subcommand

[super-structure]

Add 'update' functionality to the dita install subcommand

[infotexture]

we'd need to be a lot more careful with the version dependency metadata for built-in plug-ins

Indeed. The safe default would be to only bump plug-ins to newer versions that are explicitly declared compatible with the installed toolkit version, and maybe provide something like the --force option install to override that default and also install newer plug-ins that aren't officially compatible with the installed version.

[jelovirt]

@infotexture I've been hesitant to try and implement anything that is a real plug-in dependency management into DITA-OT, just because I expect it to be in the class of Really Difficult. But warning about removing a plug-in that some other plug-in depends on should not be too difficult 🤔

[jelovirt]

These are good suggestion, but there are some problems that come with them.

The "unable to delete" is a result of OT trying to delete a JAR file it's currently running. A fix would be to run install and uninstall subcommands with a classpath that only contains the core libraries, none of the plugin libraries. For Bash CLI this is a simple fix, but for Windows the problem is that none of the main developers has a Windows machine. Maybe a fix for Windows could be left for the community to contribute.

[jelovirt]

@infotexture @robander I wonder how much of an issue it will be that

1. User installs DITA-OT version 4.2 that ships with plug-in X version 7.3
2. User runs update subcommand and plug-in X version is updated version 9.1
3. User runs into problems with plug-in X transtype and reports an issue for DITA-OT 4.2

We'd need to change our issue reporting templates so that you'd need to paste in the results of running dita plugins that contains the list of plugi-ns with version numbers.

Another problematic case is

1. User installs DITA-OT version 4.2 that ships with build-in plug-ins version 4.2
2. User runs update subcommand and all build-in plug-ins are updated to version 4.3
3. User runs into problems with a build-in plug-in because they rely on some feature added in DITA-OT 4.3

It would also mean that we'd need to be a lot more careful with the version dependency metadata for built-in plug-ins.

[infotexture]

@jelovirt While you're thinking about safeguarding uninstall in #4328, we might want to consider reviewing plug-in dependencies as part of the process, so if someone tries to remove a plug-in that another depends on, the action fails with a warning that explains why.

Here's an example of how Homebrew handles this:

❯ brew uninstall ruby
Error: Refusing to uninstall /opt/homebrew/Cellar/ruby/3.2.2_1
because it is required by gem-bundler, which is currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies ruby

We can treat this as a separate issue of course, just wanted to mention it here in case it makes sense to combine them.

[super-structure]

@jelovirt It seems obvious now that you say that's why it could it be removed; not sure why that hadn't occurred to other than having never tried that command before. As a Windows user, I'll be glad to work on (at least) the ability to kill a running .jar file. I think it's also a pretty straightforward thing to do via a command based on a cursory search in StackOverflow.