Crypto "utils" API to abstract use of Bouncy Castle

[msgilligan]

We are currently using Bouncy Castle for 6-7 algorithms. This issue lists those algorithms, suggests possible alternative implementations and proposes creating some kind of Crypto utilities interface to provide an abstraction that will eventually allow alternative implementations.

secp256k1-jdk will provide an alternate implementation of ECDSA (and Schnorr too!) but will not provide the other algorithms used by bitcoinj. Our current plan for release 0.18/0.19 is to abstract ECDSA usage with secp256k1-jdk. It is not a goal of the 0.18 or 0.19 releases to replace the Bouncy Castle dependency for the remaining algorithms. The focus of this issue is abstracting the use of the other algorithms and there is no proposed time-frame for doing so.

1. ECDSA -- secp256k1-jdk. See Issues #3389 and #3352
2. RIPEMD160Digest -- Used for Bitcoin addresses. Not available in JavaSE. Will need alternative implementation. See Issue #3964
3. SHA3 -- Used for Tor onion addresses. Is available in Java 9 or later, but will need alternate implementation for Android. See PR #3923
4. HmacSHA512 -- Is available in JavaSE and Android. We can migrate immediately. see PR #3910 and #3911
5. PBKDF2WithHmacSHA512 -- we currently have our own implementation, but PR #3251 switches to Bouncy Castle. We could also use JavaSE.

Wallet:

6. Scrypt -- Used for wallet encryption. Not available in JavaSE. Will need alternate implementation.
7. AES -- Used for wallet encryption. Is available in JavaSE.

We should work to refactor our code to reduce dependencies on the Bouncy Castle API by refactoring use of these BC algorithms into classes like CryptoUtils. We can then design an API and create a separate module that implements this API with Bouncy Castle. This could potentially allow us to choose between bcprov-jdk15to18 and bcprov-jdk18on (see PR #2376) in bitcoinj applications.

If I'm missing any algorithms or other usages of Bouncy Castle please comment.