Add mechanism for updating Java

[hinerm]

‼️ NB: requires SJC release before merging ‼️

[hinerm]

This logic should be moved to Jaunch or ClassLauncher instead

[hinerm]

Improvement to the logic is needed in that we're only really considering managed versions of Java right now.

• The message that "a newer Java is needed" doesn't make sense if the user is manually running Java 21 (although I think this can only happen with a manually Jaunch'd installation?)
• After declining an upgrade, we keep asking. There needs to be an ignore option, or only ask again if there's a version change (along with a way to manually trigger the upgrade, ideally, if someone declined and then changes their mind)
• The path to the JDK should be relative instead of absolute, to preserve integrity if the app dir is moved

[ctrueden]

the user is manually running Java 21 (although I think this can only happen with a manually Jaunch'd installation?)

There are lots of ways users can run Fiji with a different OpenJDK 21 than the one we download and unpack, without having set up Jaunch manually. Assuming the user has installed SciJava Ops by enabling the SciJava Ops update site etc., they could then:

• Manually download a different OpenJDK 21 bundle and unpack it into their Fiji.app/java/<platform> folder
• Launch with ./fiji-linux-x64 --java-home /path/to/my/openjdk-21.
• Rename their java folder to java.disabled and have OpenJDK 21 installed in some other fashion, such as system-wide, via conda, cjdk, or sdkman.

[hinerm]

When comparing java versions we need to know if the current Java is a bundled Java or custom.
If the java is same or newer then we don't care.
If the Java version is older, we have to look if it's bundled or not. If so, we feel confident in updating. If not, notify the user?

We can use the FileDownloader logic for actually doing the downloads.

For the update checking comparison timing, instead of doing it pre-emptively, we can do it when the application fails to launch because of Java versions. But we probably still want a mechanism tied to the updater, which could mean adding a dependency on imagej-launcher.

Ideally this update-time check would be migrated to the ImageJ-Updater component

[hinerm]

Other consideration: how can we get the Java updating to work with the command line updater?

In the launcher we could have a boolean updateHeadless that defaults true and just does the update logic if headless by default.

For the command line updater, could we easily add an update-java target?