Design and implement replacement for PolicyContext

`PolicyContext` inherently depends on `checkSecurityPermission` to satisfy the requirement of configuration security:

> The Application server must bundle or install the PolicyContext class, and the containers of the application server
> must prevent the methods of the PolicyContext class from being called from calling contexts that are not authorized
> to call these methods. With the exception of the getContextID and GetHandlerKeys methods, containers must restrict
> and afford access to the methods of the PolicyContext class to calling contexts trusted by the container to perform
> container access decisions. The PolicyContext class may satisfy this requirement (on behalf of its container) by
> rejecting calls made from an AccessControlContext that has not been granted the "setPolicy" SecurityPermission, and
> by ensuring that Policy providers used to perform container access decisions are granted the "setPolicy" permission.

Given it's a final class container don't have much means of satisfying this requirement. We therefore need to decouple the security decision from the class, or separate the API based on its security requirements. We might need to combine some of these approaches:

## ServiceLoader-backed implementation instead of final class

Similar to MicroProfile Config, or Rest's `RuntimeDelegate`, the application server should be responsible to provide implementation of PolicyContext via service loader, where it can implement necessary security/context checks for modification methods.

## Separation of contracts

The API of the class could be reduced to only support unprotected methods (`getContextId`, `getHandlerKeys`) and other means defined for interacting with the context, that would be passed from trusted context to related classes. Though such API change could be quite disruptive.

Start with the PolicyContext API and the cited configuration-security requirement. Compare the proposed ServiceLoader-backed implementation with separating protected and unprotected contracts, then check the surrounding authorization API for compatibility constraints. Done means an agreed replacement design and implementation that lets containers enforce the required security checks.

Written by the indexing model from the issue text.