iteration / thread race condition fixes

[mweal-ed]

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.

[mweal-ed]

Note: I was probably a little pre-mature on submitting this. If it is used without "USE_THREAD", it will break the _async functions.

[oliviermartin]

Thanks a lot @mweal-ed to have found the reason of this bug. My understanding is without USE_THREAD (default) async functions do not work anymore and with USE_THREAD it fixes the issue. Should we enable USE_THREAD by default?
Should I wait before merging it with USE_THREAD? I will come back on gattlib in a couple of weeks. I will have more time to test it and/or offer an optimal solutions.

[mweal-ed]

You are correct, however I think there may be some hidden problems when using threads.

[mweal-ed]

I am not that experienced with git, so let me know what you want me to do to so we can proceed with these (and my other) fixes.