Lazy init stringClass in ssl.c before using to avoid crashes

[csutherl]

I spent some time digging into the SSL.getCiphers() test that caused the JVM to crash (following up on the dev-list thread mentioning it); I found that crashes occur when calling the method without first calling SSL.initialize(). The root cause is that ssl.c and sslcontext.c each declare their own static stringClass variable (ssl.c:43 and sslcontext.c:30). The variable in ssl.c gets initialized only when SSL.initialize() is called (ssl.c:221-223), but SSL.getCiphers() uses it directly without any NULL check (ssl.c:1104). In contrast, sslcontext.c handles this correctly: SSLContext.make() uses lazy initialization with a NULL check (sslcontext.c:410-415) before any method uses the variable.

The crash occurs when code calls SSLContext.make() (which initializes stringClass in sslcontext.c but not in ssl.c), then calls SSL.getCiphers() without having called SSL.initialize() first. The method appears unused in Tomcat proper, so I think we have two options:

1. Fix it by adding the same defensive NULL check that works in sslcontext.c:410-414, which is what this PR does
2. Remove the method as it appears to be dead code

Fixing the issue is just a few added lines, and provides different information than SSLContext.getCiphers() (per-connection negotiated ciphers vs context-level configured ciphers) so it may be useful to keep for any user that might want to do so in the future.

[markt-asf]

LGTM.