LPS-39137 PACL can only be enabled when an existing security manager is enabled, the check can then be static, simplify logic where applicable
LPS-39137 eliminate the active/not active states of PACL, it's either enabled, or it's not
LPS-39137 track every url which can be used as a plugin ProtectionDomain.CodeSource.Location

- some app servers don't assign the ClassLoaders to the ProtectionDomain of created resources, like JSP/Web resources classes
LPS-39137 refactor to strictly enforce local PACL permissions - stage 1 - simplification
LPS-39137 simply PortalPermissionCollection (inherit from reusable parent)
LPS-39137 detect re-entry caused by the parent _policy's own permission checks and let those succeed.

- reading a policy file, instantiating a permission class through reflection, etc.
LPS-39137 indent only
LPS-39137 log failures in DEBUG mode
LPS-39137 don't forward PACL permission types to the parent _policy
LPS-39137 refactor to strictly enforce local PACL permissions - stage 2 - reorganize around not delegating to parent _policy and relying more on the locations
LPS-39137 when the caller is ProtectionDomain return false because it means the PortalPolicy already failed the check
LPS-39137 PACL-ize ReferenceRegistry
LPS-39137 fix NPE in FileChecker (classes are allowed to not have a package)
LPS-39137 make sure message bus is correctly prepared for PACL
LPS-39137 execute PACL tests in a security enabled JVM
LPS-39137 fix NPE in PACL test plugin deployment
LPS-39137 correct log category name
LPS-39137 setup Tomcat with security manager enabled

invoke as:

ant -f build-dist.xml unzip-tomcat -Djava.security=true
LPS-39137 setup Glassfish with security manager enabled

invoke as:

ant -f build-dist.xml unzip-glassfish -Djava.security=true
LPS-39137 don't allow anti jar|resource locking at all when security is enabled