JEP 124 Potential API Changes

Several commments on JEP 124 came in too late to be addressed in JDK 8 M2 as the CCC was already final. These will be evaluated further and addressed post-M2.

Discussions at: http://mail.openjdk.java.net/pipermail/security-dev/2012-May/004895.html

1. Add a public boolean isRevocationCheckingSupported() like method that indicates whether use of
getRevocationChecker() is supported so that a caller doesn't need to catch the
UnsupportedOperationException

2. The getRevocationChecker methods should state that each invocation returns a new CertPathChecker instance. Also, they are all missing an @return tag.

3. Add clarification to the PKIXRevocationChecker that it will be used as the mechanism for checking revocation regardless of the value of the PKIXParameters.isRevocationEnabled setting. It is the default revocation checking mechanism of the provider.
More suggestions from the code review:

- Add an overloaded CertPathChecker.init(boolean forward, CertPathParameters params) that allows a CertPathChecker implementation to access the CertPathParameters specified in a CertPath build or validation. This would be useful, for example, if you wrote a custom PKIXRevocationChecker that wanted to access CRLs specified in the PKIXParameters.
Add a clarification to the class summary of PKIXRevocationChecker that the ocsp.enable property is ignored and does not affect the behavior when you add a PKIXRevocationChecker to PKIXParameters.