Remove support for running JavaFX applications with a security manager.

The Java Security Manager was deprecated for removal in JDK 17 by JEP 411 [1]. It will be permanently disabled soon, possibly in JDK 24, as proposed by candidate JEP 486 [2]. Once this is done, System::getSecurityManager will unconditionally return null, System::setSecurityManager will unconditionally throw UnsupportedOperationException, and running "java -Dsecurity.manager" will cause the VM to exit with a fatal error.

Initial work needed to implement this:

* Fail fast at startup if the Security Manager is enabled

* Remove -Djava.security.manager and all security policy files

* Delete all tests that depend on the Security Manager; some might have value as functional tests, so could be reworked instead of removed. 

* API spec change to remove mention of security manager (including mention of throwing SecurityException)

I will file additional JBS issues to track follow-up work to cleanup the remaining calls to the security manager methods that are deprecated for removal. The follow-up work can be done independently of the timing of the integration of JEP 486 into JDK 24.

Follow-on issues for JavaFX 24:

* Remove all calls to doPrivileged (there are 350 such calls in 168 files)

* Remove all other calls to AccessController (48 calls in 33 files)

* Remove all remaining calls to System::getSecurityManager (45 calls in 27 files)

* Remove calls to deprecated SM methods from PlatformUtil and MethodUtil in javafx.base (these are lightly modified copies of those classes in java.base so I will check how they are being handled)

* Remove all uses (either throw or catch) of the deprecated AccessControlException : : 4 occurrences in 4 files

* Remove all occurrences where we throw a SecurityException; check all place where we catch it (and consider whether it is needed)

* Check and remove any remaining usages of other SM methods that are deprecated for removal by JEP 411

* SecurityManager 2 files (in addition to the ones that call getSecurityManager)

* AccessControlContext: 169 occurrences in 65 files (many are associated with doPriviliged calls, so should be rechecked once doPriv is removed)

* Utility method for fail fast SM check (if we keep the check, else remove it)

NOTE: I had earlier thought that the "fail fast" could be temporary until all follow-up work is done, but I now think we should leave it in for JavaFX 24, possibly adding it to two other classes -- ReflectUtil and MethodUtil -- depending on the follow-up work needed for those classes. If we do end up leaving it, I'll create a utility method in javafx.base that will use reflection to check whether the security manager is enabled, so we don't leave in a call to a method (System::getSecurityManager) that is deprecated for removal.

We might also file additional follow-up issues, not necessarily targeted for JavaFX 24:

* Consider deprecating for removal the following security-related APIs in JavaFX
    * FXPermission (this PR changes the spec to make it clear that it is no longer used to control access to resources)
    * WebErrorEvent.USER_DATA_DIRECTORY_SECURITY_ERROR (if there is no other use than to report a SecurityException that can no longer happen after the security manager is removed)

[1] https://openjdk.org/jeps/411
[2] https://openjdk.org/jeps/486