Incomplete spec for most of the getInstances

This bug is a result of 4972556, in which this problem is pointed out.
I'm fixing all of 4972556 but this issue, since this applies to the entire
architecture (JSSE, JCE & JCA)

In almost all of the factory getInstance methods, there is no specification
for what happens when you pass null to the algorithm. e.g. JDK-8166350
complains about SecureRandom.

There are a few classes:

    ExemptionMechanism
    KeyAgreement
    KeyGenerator
    SecretKeyFactory

which specify NullPointerException, so I believe we should probably
be consistent and update all of the remainder to throw the same, since
they all use the same underlying code via sun.security.jca.GetInstance.

Also, the GetInstance code should do an up-front check for null, rather
than waiting for an actual null-pointer usage to cause this to fail.


I also noticed some other problems while I was down there.

CertificateFactory
    getInstance(String,String) - doesn't throw IllegalArgumentException

CertPathBuilder
CertPathValidator
CertStore
Cipher
ExemptionMechanism
KeyAgreement
KeyGenerator
Mac
SecretKeyFactory
    getInstance(String,String) - say "if provider is null"
but don't say anything about what happens if the
string is empty.

All of these issues will probably need a CCC, so this bug can
be the catch-all for it.

###@###.### 2004-01-29
(From bug JDK-6302704) The specification of the methods

  getInstance(String protocol)
  getInstance(String protocol, String provider)
  getInstance(String protocol, Provider provider)

of the SSLContext class doesn't state that methods throw NullPointerException.

But these methods throw NullPointerException if the protocol argument is null.
Not that jdk 1.4.2 correctly throws NoSuchAlgorithmException.

(From bug JDK-6302716) The specification of the methods

  getInstance(String protocol)
  getInstance(String protocol, String provider)
  getInstance(String protocol, Provider provider)

of the TrustManagerFactory class doesn't state that methods throw NullPointerException.

There's the same problem at class KeyManagerFactory.

From JDK-8166350, the same can be said of SecureRandom.