ChatViewer: Chat fragments updated only if they need to be updated (onChatChanged, onContactsChanged)

OTRManager: sessions are created again after "plaint_text" of "finished" status. Debug logging added.

Contact list navigation drawer "XMPP accounts" made clickable and lead to "XMPP accounts" preferences screen.

1.0.12

#456 Fix: hardware button menu fix: ContactList and ContactEditor  uses toolbar menu (setSupportActionBar removed).

 If contact is null no options menu created.

1.0.11

http://developer.android.com/design/patterns/navigation.html#into-your-app

Revert "Correctly use SRV specified hostname for cert validation (#204)"

Current chat notifications fixed (sound and vibration effect for new message in  current chat if the option is turned on). #446

1.0.10

1.0.9

Correctly use SRV specified hostname for cert validation (#204)

Initially the XMPPTrustManager queried getServiceName from the
ConnectionConfiguration and used that for certificate validation. This is a
bug, because the serviceName corresponds to the hostname of the jabber id. That
is, if we're trying to connect for account foo@bar.com it corresponds to
bar.com.

However, we are properly doing a SRV lookup to see which server hosts the
actual XMPP server for bar.com, which may be on a different hostname. For
example, everyone hosting their XMPP at fastmail.com will have their XMPP
server on chat.messagingengine.com. The XMPPTrustManager will then try to
verify the server's certificate of chat.messagingengine.com against the bar.com
it expects, which will obviously fail. This issue renders it impossible for
anyone using a 3rd part XMPP server to connect to their account.

The correct approach is to use the hostname returned by the SRV lookup as the
hostname checked by XMPPTrustManager. That is, if our SRV lookup for bar.com
returns chat.messagingengine.com as the XMPP server, we should validate that
the certificate corresponds to chat.messagingengine.com, NOT bar.com