Make security manager behavior pluggable

[ThrawnCA]

To support multiple kinds of special permissions, or other behavior like hard-blacklisting specific permissions, will require a more pluggable approach than just subclassing the security manager.

Idea at this point is:

• Define a list of resolvers when security manager is constructed, probably using a comma-separated list of class names in a system property.
• Each resolver defines a method that accepts a permission, a list of classes representing the call stack, and a list of classes for which permissions have not yet been found. The resolver applies its logic (eg checking guest passes) and returns a sublist of the classes that still don't have permissions; or, if the resolver knows that permission definitely should not be granted (eg if it represents a permission blacklist), throws SecurityException.
• The security manager assembles the initial list, probably removing itself from the call stack in the process, and passes it to the first resolver, then passes the result to the second resolver, etc.
• If unresolved classes remain after all resolvers have run, then fail.

Points to note:

• Even if the list of unresolved classes becomes empty, still pass it to the remaining resolvers, so that they can implement strategies like permission blacklisting.
• We also need to provide a way for the resolvers to check whether a class implies a permission. Either we provide a privileged callback, or we pass them the PermissionCollection for each class.

[ThrawnCA]

Probably best to pass the PermissionCollection to each resolver, because:

• Other code then cannot check whether a class implies a permission (even though this action is not normally dangerous), because only the resolvers specified at JVM start time are given this information; and
• Performance will probably be better, especially if we cache the permission collections.