Remap usages of Applet and friends

[keastrid]

Fixes #278

This PR attempts to handle the cases of old plugins compiled before the removal of Applets in Java 26 that still reference those methods by remapping plugin classes at runtime to reference stubbed versions*.

The stubbed version of Applet unconditionally throws with an exception saying Applets were removed in the offchance an instance is somehow obtained. Javadoc and deprecation annotations were added where applicable, with placeholders in the Java 26 versions of the classes to specify the IJ version the behavior changed in.

This sets up a system to use Multi-Release Jars. The Java 26 MRJ duplicates the needed classes to allow for the signature of IJ#getApplet to change since remapping IJ's own classes is trickier. The pre-26 versions of the classes still reference Applet, so when running on pre-26 versions IJ should behave as it does now.

*It is also possible to remap to Object, and from testing with the Oracle jdk, so long as the plugin properly null checks the applet instance, there is no issue of exceptions being thrown for the nonexistent methods. I do not know how other JVMs will behave, but I imagine it would be the same. See Object version here.

Help testing on Java versions before 9 and with plugins using java modules would be appreciated.

Tested by running the following plugin with both Java 21 and 26:

public class AppletTest implements PlugInFilter {
	private Applet applet;
	
	@Override
	public int setup(String arg, ImagePlus imp) {
		applet = IJ.getApplet();

        if (applet != null) {
            IJ.log("Applet found");
			IJ.log(applet.getName());
			IJ.log(applet.getAppletInfo());
        } else {
			IJ.log("No Applet found");
		}
		
		return DOES_ALL+NO_CHANGES;
	}
	
	@Override
	public void run(ImageProcessor ip) {
	}
}