This is a fix for issue 31 where there is an occasional race condition because the glib GMainContext g_gattlib_thread->loop_context is run in two threads (explicitly not allowed in glib documentation).

I have provided 2 different fixes controlled by defining USE_THREAD in gattlib_internal.h. The default operation does gattlib_iteration's as required. When USE_THREAD is defined a main loop is run in a separate thread (this is the way it is done in the existing code) for processing glib events. gattlib_iteration is still called but g_main_context_iteration is only called if gattlib_iteration was called from the same thread as the g_main_loop.

I do not like the USE_THREAD mode because:

1. I do not think it is necessary
2. The way it is implemented it is not very cpu friendly because it will be continuously looping on the event complete variables.
3. I have tried using a mutex or semaphore for watching the thread complete variables instead, but they seem to create the same race conditions we started with. This makes me think there is something in the Gatt code that is not thread safe. I have not been able to track it down.