Blueproximity counts sleep cycles instead of real clock time

[Thor77]

In Proximity.run() loop, blueproximity calculates sleep cycles that it assumes to be of 1 second. Unfortunately BluetoothSocket.connect() blocks for long time if device goes out of range (for me it's usually 3-6 seconds) before it gives up. This makes computer locking time settings completely wrong and the locking time can be over 30 seconds in addition to the detection of device losing contact (that can easily take over 10 seconds by bluetooth driver). Second place where program blocks is the gobject.timeout_add() method. This is actually executed in the same thread as the user interface and if there are long-running processes (like playing a few second sound clip) or if I change the BluetoothSocket.connect() method to use this method, GUI will be unusable when device goes out of range.

This patch uses real clock time (with sleep detection) to handle bluetooth proximity events and separate threads for program and connection execution so that no blocking operation can prevent other operations from executing.

[Thor77]

Patch that uses real clock time when deciding about events and makes blocking operations to be run in separate threads. Attached file: https://sourceforge.net/p/blueproximity/bugs/_discuss/thread/1b0e9a87/5ea5/attachment/blueproximity-non-blocking.diff (By barro)