Remove SingleInstanceService (and the --singleton command line option) from jpackage.

History:
----------

The javaws SingleInstanceService was introduced in JNLP specification version 1.1 in 2003 and implemented as part of javaws included in Java 1.5.0.

Initially it was implemented in the native javaws launcher to avoid the overhead of launching java for the second and subsequent launches of a Single-Instance enabled jnlp application.

Later it was also implemented in pure java code to cover the cases where the jnlp file is not available to the native launcher.

Java Packager Implementation:
------------------------------------------

The Java Web Start code for SingleInstanceService was basically copied first into JavaFXPackager, then JavaPackager in JDK9, and finally to the jpackage tool targeted at JDK13.

The native application launcher relies on a --singleton option to jpackage to determine if app should be launched or an existing running instance should be notified.

If an app created with --singleton option is already running and has registered a SingleInstanceListener, then when another instance is run the native launcher will invoke that listeners newActivation() method (same as Java Web Start).

If an app created with --singleton option is already running and has not registered a listener, then when another instance is run the native launcher will just "activate" the existing instance (without passing it any of the arguments used in the second invocation.)

In either case secondary launchers will not create a second java process.

Stand-Alone Implementation:

Between 2003 and 2019, the speed of the hardware java is running on, and performance improvements in the java platform itself have made huge improvements in the start-up time of the Java VM.

Because of this the primary reason for implementing single instance functionality in the native launcher(s) (instead of in pure java) is greatly diminished.

Without the need to implement this in the native launcher(s), the implementation of Single Instance functionality is greatly simplified.

I have implemented a prototype of a pure java implementation (Singleton.java), implementing the public methods running(), start(), stop(), and invoke(), which can be used as follows:

-----------------------------------------------

package com.myapp;
import com.oracle.si.Singleton;
...
public class MyApp implements Singleton.SingletonApp {
...
    public static void main (String[] args) {
        String id = "com.myapp.MyApp";
        if (Singleton.invoke(id, args)) {
            // could either system.exit() here, or include all the rest of main in the else
        } else {
            MyApp myapp = new MyApp(args);
            Singleton.start(myapp, id);
            ...
            Singleton.stop();
        }
    }
    public void newActivation(String[] args) {
        ...
    }
}
--------------------------------
(note: only invoke() and start() are strictly needed, since invoke() will return false if running() is true, and exiting the app will accomplish everything stop() will do)

I don't see any reason to include SingleInstanceService as a part of jpackage in jdk.jpackage.runtime.singleton package.

Such a class could either be part of java, provided by the application itself, or published by Oracle as a demo or included in other documentation.