LPS-26321 Add methods that will be invoked by test-pacl-portlet
LPS-26321 Previously, HttpImpl would generate sockets in a separate thread if it failed to open a connection the first time. The new PortalSecurityManager will throw a SecurityException if a portlet is trying to open up a socket that it is not configured to be able to access. That SecurityException is caught as a reflection exception which causes commons http it to use a separate thread to attempt to create the socket again. It succeeds the second time because it uses a new thread to do it. That new thread is seen as coming with the portal class loader so the caller is assumed to be the portal and not the portlet class loader's portlet caller. This change ensures that it fails properly if a SecurityException is thrown.
LPS-26321 the permissions tag should not use PortalClassInvoker, because then every portlet that uses that taglib would require access to reflectoin for the portal class loader. We want to be able to lock that down in the security manager.
LPS-26321 PACLPolicy interface. This interface is used to determine if a portlet is allowed to do something. It represents some of the security manager limitations (not all because somethings aren't applicable) plus additional portal specific limitations like which portal services it can access.
LPS-26321 The Base policy is a helper. The Inactive policy allows everything. The Active policy checks for permissions based on what is specified in liferay-plugin-package.properties.
LPS-26321 Read liferay-plugin-package.properties to register and unregister PACL policies.
LPS-26321 Add an advice to intercept all generated ServiceBuilder services. This checks both a portlet accessing a portal, and a portlet accessing another portlet.
LPS-26321 Within the portal, when UserLocalServiceImpl uses its injected reference to UserPersistence, that reference is virgin and not wrapped with a PACLBeanHandler to check for permissions. But if someone uses UserUtil to locate UserPersistence, then we are assuming that only someone outside the portal would make that call. At that point, we return a reference wrapped with PACLBeanHandler. So if a portlet doesn't have access to UserPersistence, then it can't use it.

Portlets also have their own persistence classes. We don't wrap any of those because those are not invokable except within that portlet. We don't allow CLP (Class Loader Proxy) for persistence beans. We only allow it for services. So we don't need to protect them.
LPS-26321 A simple logging statement to prove to myself that each portlet created a different instance of that class.
LPS-26321 First cut of the security manager.
LPS-26321 Temporarily force everyone to use the liferay security manager. PACL doesn't work without it. Will have to find a better way than changing the default property value.
LPS-26321 Initial cut for FilePermissions, two of the tests don't pass though, see test-pacl-portlet
LPS-26321 Fix issue with tests because deleting and writing of files also checked for read permissions
LPS-26321 Policy should use plural form for keys
LPS-26321 Add debug so we can tell which file permissions are read
LPS-26321 Protect DynamicQuery
LPS-26321 Only use the portal security manager if PACL is enabled.  Faster performance. Add helpful log messages to tell people how to enable it if they are using another security manager.