Fix inadequate certificate validation

Proper host name validation was not being performed for certificates
kept in the local keystore.  If an attacker could convince a user to
accept and store an attacker's certificate, then that certificate
could be used for MITM attacks, giving the attacker access to all
connections to all servers in all accounts in K-9.

This commit changes how the certificates are stored.  Previously, an
entire certificate chain was stored for a server (and any of those
certificates in the chain were available for validating signatures on
certificates received when connecting).  Now just the single
certificate for the server is stored.

This commit changes how locally stored certificates are retrieved.
They can only be retrieved using the host:port that the user
configured for the server.

This also fixes issue 1326.  Users can now use different certificates
for different servers on the same host (listening to different ports).

The above changes mean that users might have to re-accept certificates
that they had previously accepted and are still using (but only if the
certificate's Subject doesn't match the host that they are connecting
to).

This commit modifies AccountSetupBasics so that it now calls
AccountSetupCheckSettings twice -- once for checking the incoming
settings and once for the outgoing settings.  Otherwise, an exception
could occur while checking incoming settings, the user could say
continue (or the user could accept a certificate key), and the
outgoing settings would not be checked.  This also helps with
determining if a certificate exception was for the incoming or
outgoing server, which is needed if the user decides to add the
certificate to the keystore.
Properly save and restore instance state in AccountSetupBasics
Add unit tests for TrustManagerFactory
Add test to make sure we don't check the wrong certificates

Right now we happily accept every certificate in our local key store as long as
the hostname matches the certificate DN. So this test fails.
It's not a huge deal since the user accepted the certificate at one point. But we
want to do this right.
Only check against the certificate stored for a server, not all of them
Eliminate the need for reflection to access hidden API
Add more unit tests for TrustManagerFactory
Extract code into new LocalKeyStore class

Also, implement the ability to configure an alternate key store
file location. This permits the running of unit tests without
clobbering the live key store file.

Also, add a test to confirm that the key store file is being written
out and reread correctly.
Move some classes out of com.fsck.k9.mail.store

The classes are just as much related to com.fsck.k9.mail.transport
as com.fsck.k9.mail.store, so having them in
com.fsck.k9.mail.store doesn't seem appropriate.

Move LocalKeyStore to com.fsck.k9.security

Move TrustManagerFactory and TrustedSocketFactory to com.fsck.k9.net.ssl
Implement pruning of old certificates from LocalKeyStore

Certificates are deleted whenever server settings are changed
or an account is deleted.
"upgrade" the LocalKeyStore

Implement an "upgrade" capability for the key store file,
and then use it to delete the old file.

The existing certs in the old file are not a security
risk, but they are now useless because the format of
their aliases was changed in commit a4440b4.  They now are
just taking up storage space and memory.

Users will need to re-accept *ALL* certificates that they had
previously accepted and are still using.  (Actually, this requirement
was effective with commit 4b57d79a.  Before that, certificates whose
Subject matched did not require re-accepting.)
Merge branch 'cert_validation' of git://github.com/k9mail/k-9.git into cert_validation

Conflicts:
	tests/src/com/fsck/k9/mail/store/TrustManagerFactoryTest.java
Move unit test class to match changes in commit 40404c3
Remove LocalKeyStore's dependency on Account to reduce coupling
Remove LocalKeyStore's dependency on K9.app
Don't delete certs. on account creation, & assure that only one instance of LocalKeyStore is created.
Eliminate the need to pass a context to LocalKeyStore.getInstance

Instead, have K9.onCreate initialize the location of the key
store file (similar to what is done with
BinaryTempFileBody.setTempDirectory).

Also, LocalKeyStore.getInstance has been changed so that it
no longer needs to be synchronized.
Merge branch 'cert_validation'
Change the way we harden SSL/TLS sockets

Blacklist a couple of weak ciphers, bring known ones in a defined order and sort unknown
ciphers at the end. Also re-enable SSLv3 because it's still used a lot.