Speed up crypto and BigInteger so NoSync and KeyPairGenerator/Failover can return to CI #15

Two OpenJDK tests were taken out of test/jtreg/passing.txt because they run too close to CI's 600 s per-test timeout. They pass, but a slower runner would fail them without any code change.

• java/security/SecureRandom/NoSync.java: 20 threads x 3,000 nextBytes/setSeed/reseed for each SecureRandom algorithm. 521 s on a CI runner (4 tests at a time), about 235 s on a small ARM board. No single algorithm stands out: SHA1PRNG and NativePRNG about 17 s each there, the three DRBG configurations 38 s, 47 s and 109 s (HMAC_DRBG). The cost is SHA and HMAC work in general.
• java/security/KeyPairGenerator/Failover.java: generates RSA keys, including the 3072-bit default. The time depends on how many candidates the prime search tries, so it varies from run to run; 214 s in one CI run.

HotSpot gets this work fast through intrinsics: SHA-1/SHA-256/SHA-512 compression (sun.security.provider.DigestBase.implCompressMultiBlock, SHA2.implCompress0 and friends) and BigInteger (BigInteger.implMontgomeryMultiply, implMontgomerySquare, implMultiplyToLen, implSquareToLen, implMulAdd). java-web runs them as bytecode.

Done when both tests take well under a third of the timeout on a CI runner and are back in passing.txt. Each run of the OpenJDK tests prints its 15 slowest tests, which shows the times.