Bouncycastle now works!

Several key changes:

 - Adding the bcprov dependency
 - Using the JDK 1.5 to JDK 1.8 lib (rather than 1.5 onwards)
 - Re-enabling the SunJCE provider (?)
 - Adding the Bouncy Castle provider (not just BouncyCastleJsseProvider)

And, crucially, downloading the Java 1.6 Export Control Crypto extensions
and putting them in the jre/lib/security folder of the Java 1.6 JDK.

Note that there are still warnings printed, and I'm not 100% sure what the true
minimum required is, but Gemini is now working on JDK 1.6, which is a first,
and allows Windows 2000 capabilities.

First forays into the Bouncy Castle.

 - Compatible with JDK 1.6.
 - Included dependencies
 - Registered the BouncyCastle JSSE (Java Secure Sockets Exention) provider.  As I understand it, it's kind of like the ImageIO Service Provider Interface situation where providers can be registered.
 - De-registered the build-in Sun provider.
 - Added the JCE (Java Cryptography Extensions) dependency in the Gemini Client, so it can use advanced cryptography.

So far it's failing on "no usable cipher suites enabled".  I'm not really sure why, as when I look at this list of enabled ones, it has a bunch of the commonly-used ones, e.g. AES 256 with Galois Counter Mode.  Are they enabled but not usable somehow?

Specifically request TLS 1.2 when creating the SSLContext.

This allows using TLS 1.2 on JDK 1.7, and is required for our client to support OS X 10.7 Lion.

This *could* cause issues with TLS 1.3 servers, but it looks just as likely that our old "SSL" value would have.  I.e. this probably won't make things any worse.

Support JDK 1.5.

This only required one change, and it was in our example, not the actual code.  Thus I'll continue the august tradition of supporting Windows 98 (and Windows 95, if you have the right JDK 1.5 installer).

On Mac, this also buys OS X 10.4 through 10.7, including PowerPC, over 1.8.

#44 - Rename variable.

#44 - Load data correctly from servers that send all the data in one TCP packet.

Known examples include tildeverse.org and gemini.conman.org.  The technique is simply reading the whole response into a buffer, rather than reading one packet and assuming it's the header.

Trim the end of the meta.

This prevents extra newlines in places where the meta is used, e.g. displaying the type of an input field to the user.

#7 - Treat non-text formats as binary; download them into a separate structure.

Allow the meta to be used by consumers of this client.

#3 - Redirect on status 30 (temporary redirect) as well as 31 (permanent redirect).

#21 - Fix links on mozz.us causing a crash.  There were two aspects of them that difffered from most others: not having a space after the =>, and having spaces in labels.

The URL support should now be much more robust.

Parse out the header meta data, and follow redirects (status 31).

Note that this does not yet implement the best practices for redirects, particularly loop detection and insecure redirect warnings.

Parse the status code integer out of the response.

Fall back to regular contents if formatted ones aren't available.

Add a formatted contents field.

Let clients grab the URL so they can handle relative links.

Add a LinkLine type, and a GeneralLine type as a placeholder.

Refactor lines into their own package.  I'm planning to have a class for each line type, so each one, when constructed with a line of input, will parse out what it needs from the contents.

Put host extracting in its own method, handle URLs with the port explicitly specified (as long as it's 1965).

Don't hardcode the host for the socket to the main Gemini project page.  Determine it dynamically.