SecurityManager Removal Epic

[starksm64]

Is your feature request related to a problem? Please describe.
The Java SE SecurityManager is being removed as per JEP-411. We need to likewise remove usage and references to the SecurityManger.

Describe the solution you'd like
Specifications, documentation, tests, TCKs, and APIs need to remove references to the SecurityManager.

Additional context
EE10 paved the way for full removal by deprecating the SecurityManager.

AB#78
AB#399

[arjantijms]

Note the usage of SecurityManager in various APIs, eg

https://github.com/jakartaee/rest/blob/master/jaxrs-api/src/main/java/jakarta/ws/rs/ext/FactoryFinder.java

[arjantijms]

Some inspiration from the work Derby has been doing towards the same goal: https://svn.apache.org/viewvc/db/derby/code/trunk/java/?sortby=date#dirlist

[edburns]

Jared Anderson wrote:

I do wonder if the entire Code Authorization section should be removed.

This is also covered in issue GH-551.

Let's look at some of the text in this section.

A Jakarta EE product may restrict the use of
certain Java SE classes and methods to secure and ensure proper
operation of the system. The minimum set of permissions that a Jakarta EE
product is required to grant to a Jakarta EE application is defined in
<<a2339, Java Platform, Standard Edition (Java SE) Requirements>>. 
All Jakarta EE products must be capable
of deploying application components with exactly these permissions.

This can be removed because the reference a2339 is just:

6.2.2. Jakarta EE Security Manager Related Requirements
The Jakarta EE 11 release removes the requirement to use a Java security manager.

I judge the remainder of the section Code Authorization can remain.