convert the assistant to use a bound thread for XMPP

This *may* solve the segfault I was seeing when the XMPP library called
startTLS. My hypothesis is as follows:

* TLS is documented
  (http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety)
  thread safe, but only when a single thread accesses it.
* forkIO threads are not bound to an OS thread, so it was possible for
  the threaded runtime to run part of the XMPP code on one thread, and
  then switch to another thread later.

So, forkOS, with its bound threads, should be used for the XMPP thread.
Since the crash doesn't happen reliably, I am not yet sure about this fix.

Note that I kept all the other threads in the assistant unbound, because
bound threads have significantly higher overhead.

Assistant.hs

@@ -223,7 +223,12 @@ startAssistant assistant daemonize webappwaiter = withThreadState $ \st -> do
 			waitForTermination
 		watch a = (True, a)
 		assist a = (False, a)
+
+		{- Each named thread is started in a bound thread.
+		 - (forkOS rather than forkIO). There are not too many,
+		 - and this deals with libraries like gnuTLS that
+		 - require only one thread access them. -}
 		startthread dstatus (watcher, t)
-			| watcher || assistant = void $ forkIO $
+			| watcher || assistant = void $ forkOS $
 				runNamedThread dstatus t
 			| otherwise = noop

Assistant/Threads/PushNotifier.hs

@@ -45,7 +45,7 @@ pushNotifierThread st dstatus pushnotifier = NamedThread thisThread $ do
 		client c jid = runClient server jid (xmppUsername c) (xmppPassword c) $ do
 			void $ bindJID jid
 			s <- getSession
-			_ <- liftIO $ forkIO $ void $ runXMPP s $
+			_ <- liftIO $ forkOS $ void $ runXMPP s $
 				receivenotifications
 			sendnotifications
 			where