As an alternative to RT-13899, I suggest we change javafx.scene.web.JSObject to not extend netscape.javascript.JSObject *at this time*, though the method signatures would be kept compatible, so in the future it could be retro-fitted to extend netscape.javascript.JSObject.

Main advantages:
* People wouldn't have to import netscape.javascript.JSObject, whichmight be a weird class to have as part of our APIs.
* No complications about deploying netscape.javascript.JSObject, who owns it, and which jar it should be in. (This may or may not be
a problem.)
* Compatible with a future change to extend netscape.javascript.JSObject, which I think is the right thing, especially if we ever want to
support Applets in webnode.
* Slightly less disruptive to the codebase and existing tests/applications.

I think the deciding factor is the class name used in the API and applications: Do we want people to write:
  import netscape.javascript.JSObject;
or do we want them to write:
  import javafx.scene.web.JSObject;
The former emphasizes compatibility with the past and the wider browser landscape; the latter emphasizes javafx as a self-contained platform. I can see arguments for either - neither is more obviously "right"

Note that the various JSObject method are declared to throw netscape.javascript.JSException. If we drop netscape.javascript.* then I suggest changing the methods to just throw a RuntimeException. (JSException extends RuntimeException, so this doesn't change anything wrt checked vs unchecked exceptions.)