Raise EscalatorClosed after all ZMQErrors

Sometimes when closing the context of Escalator client
ZMQErrors were printed. This commits treat all ZMQErrors
as a reason to close the client.
Catch EscalatorClosed in drivers
LocalStorage: Catch EscalatorClosed in threads

Onitu can't catch exception in threads launched by drivers.
The drivers should catch those exceptions themself.
Rewrite Onitu startup. Needs a patched Circus.

This commit should remove most zombies issues (cf #101).
We now use the loop provided by Circus instead of
creating a new one. This allows us to use Circus' default
exit system.
The motivation behind using our own loop was to be able
to call a coroutine after the starting of the watchers.
This has been made possible by a patch to Circus which
should hopefully be integrated to the main release.

We now don't use use add_callback to add the watchers
but yield, which should prevent any conflict error.

This commit also fixes some issues when Onitu is given
a wrong setup file.
Rewrite test_startup. Test wrong setups.
Add the 'drivers' folder to flake8 list in tox
Reduce the graceful timeout of the processes from 30s to 1s
Add Circus fork to tox
Fix ImportError in Dropbox tests
Fix error in test_startup with Python 3
Catch EscalatorClosed in S3 CheckChanges thread
Catch EscalatorClosed in Drobox CheckChanges thread
Catch EscalatorClosed in Hubic CheckChanges thread
Accept ONITU_TEST_DRIVER in tox
Fix Dropbox case-conflict asymmetry.

The problem was that Dropbox, a case-insensitive service, treats
all filenames as all lowercase. This is a big problem for Onitu
and other services who don't have this constraint: we don't want
to trigger new transfers and detections for a file that is only
the same, but renamed against our will just because of one
service's limitations.

To fix it, we established in the Dropbox driver a
"virtual file mapping" system that permits Onitu to know, in case
of a conflict on Dropbox, what is the matching file on Onitu side.
Dropbox will have its own name for the duplicate created out of the
case conflict, and Onitu will keep the "normal" filename on its side.
Modifications of the file to, or from, Dropbox are transferred with
the good filename, depending on which side we're on.

It is a complex solution for a simple problem, but there's no real
good way to handle it, except not creating case conflicts. User
should be strongly advised about this problem, since this is a
rather confusing system (the same file gets two different names
on each side). To promote this idea, I put a lot of warnings
in each piece of code dealing with case conflicts in order to get
user's attention.

- As a consequence, we don't overwrite files on Dropbox anymore

- Change the detection system as the old one we used is deprecated

- Some refactoring
Randomize the test root folder for Dropbox
google driver, still need to test with python3 and do move detection on drive