Don't touch SecureRandom!

Take out the code that tries to seed SecureRandom.  JDK 1.8 will use a non-blocking source of data, and there's a fair amount of complexity which can result in SecureRandom not being seeded correctly.  Because of the risk of insecure initialiation and the overall code complexity, it's safer to take this out entirely and let JSSE deal with it.

Original motivation: http://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html

Configurable Secure Random-Number Generation in JDK 1.8: http://openjdk.java.net/jeps/123
Using SecureRandom: http://moi.vonos.net/java/securerandom/
Mailing list comment on SecureRandom internals: http://mail.openjdk.java.net/pipermail/security-dev/2013-April/007151.html
Bug resulting from someone being clever and setting the seed: http://lists.owasp.org/pipermail/esapi-user/2014-April/001151.html
A huge bug report discussion from JRuby: https://github.com/jruby/jruby/issues/1405
Issues when using java SecureRandom: http://www.cigital.com/justice-league-blog/2014/01/06/issues-when-using-java-securerandom/

Ideally, if we must handle a PRG directly, call SecureRandom.getInstanceStrong() and call sr.nextBytes() to seed, or pull from /dev/urandom directly, but the best thing to do now is to not touch it.